CPU requirement / Core™ i9-9820X

Hello team! Thank you for your support!
Let me confirm for just in case.
Intel Core™ i9-9820X CPU is not supported by ROCm 2.4.25 yet?
My chipset is X299, with Ubuntu 16.04, and attached GPU is RADEON VII. When I run the "clinfo", then the following result has appeared. As you can see, nothing appeared.
johndoe@jsai2019:~$ clinfo
Number of platforms                               0
johndoe@jsai2019:~$ lspci | grep VGA
19:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 20 (rev c1)
67:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 20 (rev c1)
johndoe@jsai2019:~$ /opt/rocm/bin/rocm-smi

========================ROCm System Management Interface========================
================================================================================
GPU  Temp   AvgPwr  SCLK    MCLK    Fan     Perf  PwrCap  SCLK OD  MCLK OD  GPU%
0    38.0c  18.0W   809Mhz  351Mhz  22.75%  auto  250.0W  0%       0%       0%
1    40.0c  21.0W   809Mhz  351Mhz  22.75%  auto  250.0W  0%       0%       0%
================================================================================
==============================End of ROCm SMI Log ==============================

But I have the same X299 chipset with Core™ i7-7800X and RADEON VII. When I run the "clinfo", then the following result has appeared.
johndoe@h030:~$ clinfo
Number of platforms                               1
  Platform Name                                   AMD Accelerated Parallel Processing
  Platform Vendor                                 Advanced Micro Devices, Inc.
  Platform Version                                OpenCL 2.1 AMD-APP (2874.0)
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_icd cl_amd_event_callback cl_amd_offline_devices
  Platform Host timer resolution                  1ns
  Platform Extensions function suffix             AMD

  Platform Name                                   AMD Accelerated Parallel Processing
Number of devices                                 1
  Device Name                                     gfx906+sram-ecc
  Device Vendor                                   Advanced Micro Devices, Inc.
  Device Vendor ID                                0x1002
  Device Version                                  OpenCL 2.0
  Driver Version                                  2874.0 (HSA1.1,LC)
  Device OpenCL C Version                         OpenCL C 2.0
  Device Type                                     GPU
  Device Profile                                  FULL_PROFILE
  Device Board Name (AMD)                         Vega 20
  Device Topology (AMD)                           PCI-E, 67:00.0
  Max compute units                               60
  SIMD per compute unit (AMD)                     4
  SIMD width (AMD)                                16
  SIMD instruction width (AMD)                    1
  Max clock frequency                             1802MHz
  Graphics IP (AMD)                               9.6
  Device Partition                                (core)
    Max number of sub-devices                     60
    Supported partition types                     None
  Max work item dimensions                        3
  Max work item sizes                             1024x1024x1024
  Max work group size                             256
  Preferred work group size multiple              64
  Wavefront width (AMD)                           64
  Preferred / native vector sizes
    char                                                 4 / 4
    short                                                2 / 2
    int                                                  1 / 1
    long                                                 1 / 1
    half                                                 1 / 1        (cl_khr_fp16)
    float                                                1 / 1
    double                                               1 / 1        (cl_khr_fp64)
  Half-precision Floating-point support           (cl_khr_fp16)
    Denormals                                     No
    Infinity and NANs                             No
    Round to nearest                              No
    Round to zero                                 No
    Round to infinity                             No
    IEEE754-2008 fused multiply-add               No
    Support is emulated in software               No
    Correctly-rounded divide and sqrt operations  No
  Single-precision Floating-point support         (core)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 Yes
    Round to infinity                             Yes
    IEEE754-2008 fused multiply-add               Yes
    Support is emulated in software               No
    Correctly-rounded divide and sqrt operations  Yes
  Double-precision Floating-point support         (cl_khr_fp64)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 Yes
    Round to infinity                             Yes
    IEEE754-2008 fused multiply-add               Yes
    Support is emulated in software               No
    Correctly-rounded divide and sqrt operations  No
  Address bits                                    64, Little-Endian
  Global memory size<PHONE_NUMBER>8 (15.98GiB)
  Global free memory (AMD)                        16758784 (15.98GiB)
  Global memory channels (AMD)                    128
  Global memory banks per channel (AMD)           4
  Global memory bank width (AMD)                  256 bytes
  Error Correction support                        No
  Max memory allocation<PHONE_NUMBER>2 (13.59GiB)
  Unified memory for Host and Device              No
  Shared Virtual Memory (SVM) capabilities        (core)
    Coarse-grained buffer sharing                 Yes
    Fine-grained buffer sharing                   Yes
    Fine-grained system sharing                   No
    Atomics                                       No
  Minimum alignment for any data type             128 bytes
  Alignment of base address                       1024 bits (128 bytes)
  Preferred alignment for atomics
    SVM                                           0 bytes
    Global                                        0 bytes
    Local                                         0 bytes
  Max size for global variable<PHONE_NUMBER>2 (13.59GiB)
  Preferred total size of global vars<PHONE_NUMBER>8 (15.98GiB)
  Global Memory cache type                        Read/Write
  Global Memory cache size                        16384
  Global Memory cache line                        64 bytes
  Image support                                   Yes
    Max number of samplers per kernel             26287
    Max size for 1D images from buffer            65536 pixels
    Max 1D or 2D image array size                 2048 images
    Base address alignment for 2D image buffers   256 bytes
    Pitch alignment for 2D image buffers          256 bytes
    Max 2D image size                             16384x16384 pixels
    Max 3D image size                             2048x2048x2048 pixels
    Max number of read image args                 128
    Max number of write image args                8
    Max number of read/write image args           64
  Max number of pipe args                         16
  Max active pipe reservations                    16
  Max pipe packet size<PHONE_NUMBER> (1.587GiB)
  Local memory type                               Local
  Local memory size                               65536 (64KiB)
  Local memory syze per CU (AMD)                  65536 (64KiB)
  Local memory banks (AMD)                        32
  Max constant buffer size<PHONE_NUMBER>2 (13.59GiB)
  Max number of constant args                     8
  Max size of kernel argument                     1024
  Queue properties (on host)
    Out-of-order execution                        No
    Profiling                                     Yes
  Queue properties (on device)
    Out-of-order execution                        Yes
    Profiling                                     Yes
    Preferred size                                262144 (256KiB)
    Max size                                      8388608 (8MiB)
  Max queues on device                            1
  Max events on device                            1024
  Prefer user sync for interop                    Yes
  Profiling timer resolution                      1ns
  Profiling timer offset since Epoch (AMD)        0ns (Thu Jan  1 09:00:00 1970)
  Execution capabilities
    Run OpenCL kernels                            Yes
    Run native kernels                            No
    Thread trace supported (AMD)                  No
  printf() buffer size                            4194304 (4MiB)
  Built-in kernels
  Device Available                                Yes
  Compiler Available                              Yes
  Linker Available                                Yes
  Device Extensions                               cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_image2d_from_buffer cl_khr_subgroups cl_khr_depth_images cl_amd_copy_buffer_p2p cl_amd_assembly_program

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  No platform
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   No platform
  clCreateContext(NULL, ...) [default]            No platform
  clCreateContext(NULL, ...) [other]              Success [AMD]
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
    Platform Name                                 AMD Accelerated Parallel Processing
    Device Name                                   gfx906+sram-ecc
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
    Platform Name                                 AMD Accelerated Parallel Processing
    Device Name                                   gfx906+sram-ecc
johndoe@h030:~$ lspci | grep VGA
67:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 20 (rev c1)
johndoe@h030:~$ /opt/rocm/bin/rocm-smi

========================ROCm System Management Interface========================
================================================================================
GPU  Temp   AvgPwr  SCLK    MCLK    Fan     Perf  PwrCap  SCLK OD  MCLK OD  GPU%
0    36.0c  19.0W   809Mhz  351Mhz  23.92%  auto  250.0W  0%       0%       0%
================================================================================
==============================End of ROCm SMI Log ==============================

I couldn't find any core i9 CPU in the installation guide.
https://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.html

i9 will be supported. There is no technical reason why it wouldn't be. The only requirement is PCIe Atomics which are supported since Haswell. Most likely your installation is not working correctly on the 16.04 system.
Output of therocminfo command might be useful for the devs if they come along. If it works then the problem is likely OpenCL related.

The SMI indicates that the kernel is working, so it could be an OpenCL issue. As @JMadgwick suggested, rocminfo is a good start since that will check the runtime, which will help to narrow down the issue between runtime or OCL.

I agree with both of the previous comments. That CPU should be supported, and it appears that the device has booted based on the rocm-smi output. However, without further details like the output of rocminfo and perhaps kernel dmesg outputs. However, since it's been quite a while since this report with no further response, I am going to close this issue.
If you still have the same problem, or a related problem, please feel free to create a new issue. Thanks!


make coreServices.httpRouter configurable, add notFound

Fixes #20742
Went a bit farther than just the bare minimum - the plugin router is now configurable in exactly the same way as the root router, if you want to change out the middleware.

hmm not sure if it really matters but hitting something like /api/not-found still returns a 200 with UI:

but it looks like this does fix invalid routes for known plugin APIs: /api/catalog/not-found returns 404 correctly
I guess the difference is that in the old setup we were able to have a catch all notFound handler for the base /api route but that would probably have to be attached between the namedRoutes and indexRouter here:
https://github.com/backstage/backstage/blob/a7e3499c6a8020c637cfc35314cd63e787ce4ab6/packages/backend-app-api/src/services/implementations/rootHttpRouter/DefaultRootHttpRouter.ts#L68-L71
but that also assumes every plugin router is prefixed to /api/<plugin-id> 🤔

Yeah i see what you mean. Hm. It's a bit tricky to get around that, gonna need some form of refactor I think 🤔

@kuangp alright, see what you think about this iteration of it!

@kuangp Thanks for the review! Yeah I saw the test error and then our wellness week arrived - gonna have to get back to that.

Heads-up that plugins/app-backend/src/service/appPlugin.test.ts fails at the moment :/

peah pkuang pointed out the same right, i moved it to draft and haven't been working on it since because it turned out to be tricky :)


fixed example pwm_blink in README.md

I noticed, that the example pico_pwm_blink does not exist. However, there is a pwm_blink example. I fixed the README with the examples there accordingly.

Sorry
I did something wrong in the contribution. Your Guidelines point out, that I should create a new feature branch. I will close This MR and fix the issue.


npm install fails on node-sass binary

npm install

<EMAIL_ADDRESS>install /mnt/c/devjm/typescript/miner/node_modules/node-sass
node scripts/install.js
Downloading binary from https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-64_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-64_binding.node":
HTTP error 404 Not Found

updating package.json to use ^4.10.0 seems to make life good again.

Installing node-sass fixes the issue.
npm i node-sass --save-dev

@Yonet
I think there could be an issue with specific node-sass version - on Windows. Are you on Windows? Can you post which version was added to your local package.json? I'll update the dependency, as I've experienced same problem recently on Windows machine.

@peterblazejewicz, I was running into other problems and I didn't have a chance to get the project to run. There wasn't any sass issues logged but I can't confirm there weren't any issues on runtime.
node-sass version: 4.14.1

thx , I've made a PR bumping with minor version, for me it's solid on Win10, compared to 4.13.*


Future: Self-defining data types

The need for this feature is still unclear, but it's worth considering.
An obvious and rather direct approach is to define a message type containing a raw block of bytes with encoded message. The message itself could be encoded in one of the existing self-defining protocol formats, e.g. Google Protobuf, BSON, etc.
Example:
void1
uint7 RECIPIENT_BROADCAST = 0
uint7 recipient
Name name
Encoding encoding
uint8[<=1024] payload

Where Name:
void2
uint8[<64] name

Encoding:
uint8 FORMAT_GOOGLE_PROTOBUF = 0
# Other formats...
uint8 format

A similar approach can be used for self-defining service calls.

I think ProtoBuf is not self defining, you have statically define
messages, like in UAVCAN. Another good encoding that we use for our
robots is MessagePack (http://msgpack.org).

@pavel-kirienko @antoinealb You will want to look at this issue:
https://github.com/mavlink/v2_playground/issues/1
It has a complete table. We're currently revisiting the whole message definition on the vehicle in collaboration with Dronecode & 3DR. There was also some interest to have the same messages on CAN, so it would be a big plus to have native support in UAVCAN for the message format. So far Cap'n Proto seems to lead in terms of features and efficiency.

First stab, at 3DR's request: https://github.com/UAVCAN/dsdl/tree/foreign_object/uavcan/foreign_object

@pavel-kirienko I'm interested in reviving this foreign_object concept for carrying multiple protocols over CAN. I see your branch with the generic 1024 byte buffer. I'm surprised FORMATS does not contain MAVLink? I think that's worthwhile. I definitely have a need for it.

You can add it to Format.uavcan. However I wonder if there is really interest in putting this kind of support in the standard, as the decoding of the payload will probably be application specific anyway.

@antoinealb  I find it useful and it's not just me. Why not include a generic interface like this in the main spec? I don't see a downside. I'll PR the branch from @pavel-kirienko
Having a bridge is very useful. Another bridges that would be helpful is I2C over CAN. I know ArduPilot would like that. Helps with migrating devices.

Revised implementation at https://github.com/UAVCAN/dsdl/pull/40


Step by step guide how to reproduce

start with new npm module
2.install stremio-addons
hook the middleware/express
hook stream.find
hook meta.find

This was idiotically opened, as the README does exactly that... exactly in that order.


Promise response.data is transformed using getData without access to raw original data and response AxiosResponse object

When migrating 0.26=>0.27 I noticed that the successAction.response.data is the transformed data after getData was applied.

The getData makes sense in the context of redux and normalization logic, however when calling a promisified action, I'd usually like to have the raw data.
Also for a reason I still do not completely understand the AxiosResponse object is not there, and the object includes only data attribute making it impossible to inspect headers and status code?

@burgalon see https://github.com/klis87/redux-saga-requests/issues/320

to sum up, I can resolve request promise only with response which is stored in reducer, otherwise for cached responses and SSR we could not recover raw responses
for now we store only data in reducer, but we could add more, like headers, statusCode
I have to use getData before resolving response for the very same reason - consistency,
In theory I could store original data too, but what about mutations together with cached query? Mutation would need to update both data and rawData, which would be very unpleasant. Now data is only one, single source of truth, no bugs, no synchronisation issues.
Hence this decision, if you want to store a data in a raw form, do not use getData to make this transformation, do it on selector level. Future version of this library will have helpers like mapQuery, mergeQueries and so on, but it is just normal reselect usage, one of the examples can be seen in readme.

Now response contains also headers and status for axios and fetch drivers, with custom driver any attr next to data is allowed


Using express.js 4 with socket.io won't start

Surprisingly everything works well when doing node app.js instead of npm start.
Why is it?
I'm using express 4.2.0 and I've done:
express node6 --hogan --ejs
cd node6
npm install
npm install socket.io

I went into the socket.io docs and I copied and pasted the code of the app.js file overwriting the one created by default. (which contains much more things)
After the pasting it would look like this:
var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);

server.listen(80);

app.get('/', function (req, res) {
  res.sendfile(__dirname + '/index.html');
});

io.on('connection', function (socket) {
  socket.emit('news', { hello: 'world' });
  socket.on('my other event', function (data) {
    console.log(data);
  });
});

It is throwing errors when doing npm start.
Why is it?
This is the dpm-debug.log:
0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\\\node.exe',
1 verbose cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose node symlink C:\Program Files\nodejs\\node.exe
5 verbose run-script [ 'prestart', 'start', 'poststart' ]
6 info prestart<EMAIL_ADDRESS>7 info start<EMAIL_ADDRESS>8 verbose unsafe-perm in lifecycle true
9 info<EMAIL_ADDRESS>Failed to exec start script
10 error<EMAIL_ADDRESS>start: `node ./bin/www`
10 error Exit status 8
11 error Failed at the<EMAIL_ADDRESS>start script.
11 error This is most likely a problem with the node6 package,
11 error not with npm itself.
11 error Tell the author that this fails on your system:
11 error     node ./bin/www
11 error You can get their info via:
11 error     npm owner ls node6
11 error There is likely additional logging output above.
12 error System Windows_NT 6.1.7601
13 error command "C:\\Program Files\\nodejs\\\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "start"
14 error cwd C:\inetpub\wwwroot\node6
15 error node -v v0.10.29
16 error npm -v 1.4.14
17 error code ELIFECYCLE
18 verbose exit [ 1, true ]

After running node ./bin/www  I get this error:
C:\inetpub\wwwroot\node6\bin\www:5
app.set('port', process.env.PORT || 3000);
    ^
TypeError: Object #<Object> has no method 'set'
    at Object.<anonymous> (C:\inetpub\wwwroot\node6\bin\www:5:5)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3

The start entry of the package.json looks like this:

"start": "node ./bin/www"

Thanks very much. This problem trouble me for a long time

I am working on socket.io in my Nodejs project. I opted for this solution in order to require the io module and send messages via sockets. The problem with it is that whenever you require the io module, you are actually instantiating a new io variable and a new connection binding, which returns the wrong object and io.sockets.connected returns as an empty object. Any thoughts on how to solve this problem ?


[mwc-drawer] Drawer not following content in a dismissible context.

Describe the bug
The drawer (dismissible) sticks at the top of the document when scrolling if appContent is longer than the drawer's content.
Expected behavior
In my use-case I was expecting the drawer to follow the content on scrolling.
I am using modal drawer on the mobile version so It's fine. dismissible on PC and tablets. On PC it's also fine because the content is all visible on the screen but on tablet I would wish my users to scroll the content and they still could have an eye on the drawer content because it displays live update information.
Screenshots
https://user-images.githubusercontent.com/2827383/111066596-183a6700-84c0-11eb-9314-6d4f1e95e063.mp4
Fixes
I could get what I wanted but just changing the css directive position on the .mdc-drawer selector, like so:
this.drawer.shadowRoot!.querySelector<Drawer>('.mdc-drawer--dismissible')!.style.position = 'fixed'

Browser Version (please complete the following information):

OS: Linux, Windows
Browser Chromium 88.0.4324.182
Version mwc-drawer version 0.20.0

@taylor-vann this might be related to your current work


Add build-base to Dockerfile

This allows the Dockerfile to be built on arm architecture.

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "patch-1" git@github.com:haydenhughes/distribution.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


Question: Maturity and Official Support

We're experiencing a run-around with NR support because this project isn't the right tier of open-source project. The specifics of the issue is not what this ticket is about:
(Using definitions from https://docs.newrelic.com/docs/licenses/license-information/general-usage-licenses/global-technical-support-offerings#h3-open-source-project-categories>)

This is a Community Project, which means that support is provided here in GitHub (and maybe NR Discuss), but that's it.

As of this writing, the latest tag is 0.41.0. There is no mention of semantic versioning either in the README, nor in https://newrelic.github.io/developer-toolkit/.

My questions are these:

Is there a roadmap for achieving 1.0.0? Are there criteria that can be shared/documented?

Do you intend to adopt semantic versioning as a software contract, and if so, which things are in/out-of-bounds? (e.g., versions of Go, versions of TLS, TLS ciphers, will they apply to the whole repo or by-package?)

The name of this project is "client", but many other vendors have "SDKs" (e.g., AWS). What is the difference between them (to you), and do you envision this project being more of one, or more of the other as it matures?

Are you able to discuss anything around the conditions under which this project would graduate from a Community Project to a Community Plus Project? (Which gains: “Support requests can be made through Github, Community, and Ticketed Support channels, depending on the service level associated with the New Relic account.”)

Hi @skyzyx, thanks for raising the issue.  Here is a rough take of where we're at today.

Is there a roadmap for achieving 1.0.0? Are there criteria that can be shared/documented?

There is not currently a 1.x plan for this project.  We've avoided releasing a
1.x so that we may remain nimble in the case we want to shift the code patterns
that are in place here.  That said, the patterns in this project are
stabilizing.
We have ambitions of generating lots of code in this project, and that may put
some amount of pressure on the code to shift slightly, and so we are leaving
the door open for change.
We can discuss a 1.x as a team and see what the right course of action is.  Is
there a concern with the version being pre 1.x that you are able to share?

Do you intend to adopt semantic versioning as a software contract, and if so, which things are in/out-of-bounds? (e.g., versions of Go, versions of TLS, TLS ciphers, will they apply to the whole repo or by-package?)

We currently adhere to semantic version for all of our releases and we
release the client as a single "atomic" release.  The version bumps reflect
change since the prior release.
With regard to TLS support, I would expect that services would constrain the
TLS support far more than this project.
I'm seeing posts like this, for example.
https://discuss.newrelic.com/t/january-tls-updates-apis-and-browser-apm/88869
For Go versions, probably v1.13+ is a reasonable constraint.
https://github.com/newrelic/newrelic-client-go/issues/474 to follow up.

The name of this project is "client", but many other vendors have "SDKs" (e.g., AWS). What is the difference between them (to you), and do you envision this project being more of one, or more of the other as it matures?

This project is intended to interface with the majority of our public facing
APIs from code.  We also wanted to avoid confusion with some of the other New
Relic Projects, like the Go Agent.
An SDK in my mind would help developers write modules, or plugins, or some
other discrete and well-defined package.  An SDK might also include tools to
create a new project, lint a project, help developers conform to newer patterns
etc.
From that perspective, I think the term client here makes sense.  With this
project, we provide a collection of packages with methods that allow users to
operate the New Relic APIs.  What the end-user code looks like, or how it
behaves is entirely out of scope here from my perspective.

Are you able to discuss anything around the conditions under which this project would graduate from a Community Project to a Community Plus Project? (Which gains: “Support requests can be made through Github, Community, and Ticketed Support channels, depending on the service level associated with the New Relic account.”)

It sounds like a matter of committing a small team to a customer SLA.  I don't
know what the future holds on this point.  Is there anything in particular
you're looking for here?

This is great, @zlesnr, and exactly what I was looking for. :)

Is there a roadmap for achieving 1.0.0? Are there criteria that can be shared/documented?

There is not currently a 1.x plan for this project. We've avoided releasing a
1.x so that we may remain nimble in the case we want to shift the code patterns
that are in place here. That said, the patterns in this project are
stabilizing.
We have ambitions of generating lots of code in this project, and that may put
some amount of pressure on the code to shift slightly, and so we are leaving
the door open for change.
We can discuss a 1.x as a team and see what the right course of action is. Is
there a concern with the version being pre 1.x that you are able to share?

Only that, in terms of semantic versioning, pre-1.0.0 simply means that there is no discernible software contract in-place yet. This means that the code I write today may not work tomorrow (more or less). As you explain yourself, you do it "to remain nimble" which I understand as a developer, but the counter-argument is that the nimbleness for you comes at the cost of reliability for me.
On behalf of enterprise customers, I look forward to a stable and supported 1.0.0 release (meaning that I get to use my super-duper, ultra-platinum, really expensive support package for this project) where backwards-compatibility guarantees are a thing, and there are other bits of software contract that I can rely on.

Do you intend to adopt semantic versioning as a software contract, and if so, which things are in/out-of-bounds? (e.g., versions of Go, versions of TLS, TLS ciphers, will they apply to the whole repo or by-package?)

We currently adhere to semantic version for all of our releases and we
release the client as a single "atomic" release. The version bumps reflect
change since the prior release.
With regard to TLS support, I would expect that services would constrain the
TLS support far more than this project.
I'm seeing posts like this, for example.
https://discuss.newrelic.com/t/january-tls-updates-apis-and-browser-apm/88869
For Go versions, probably v1.13+ is a reasonable constraint.
#474 to follow up.

It's great to hear that the project views itself as being semantically-versioned… but that's not written down in any obvious places (e.g., README), and the reality is that most software project still have not adopted semver, so I (as a consumer) can't assume such a thing.
But semantic versioning only addresses backwards-compatibility — and even then, only addresses the compatibility of some parts and not others. It's not a silver bullet. If, in the future, all New Relic endpoints suddenly expected TLS 1.3 or HTTP/3 or something else that doesn't impact function signatures, are they in-scope, or out of scope for the client API? Do you bump major version, minor version, or patch for such a change?
That's why I'm asking the follow-up questions. For all the things that semver covers, there are other things that it does not (and was not designed to) cover. If the answer is "I'm not quite sure yet", that's cool. But I think this is an example of something that needs deep thought before 1.0.0. 👍

The name of this project is "client", but many other vendors have "SDKs" (e.g., AWS). What is the difference between them (to you), and do you envision this project being more of one, or more of the other as it matures?

This project is intended to interface with the majority of our public facing
APIs from code. We also wanted to avoid confusion with some of the other New
Relic Projects, like the Go Agent.
An SDK in my mind would help developers write modules, or plugins, or some
other discrete and well-defined package. An SDK might also include tools to
create a new project, lint a project, help developers conform to newer patterns
etc.
From that perspective, I think the term client here makes sense. With this
project, we provide a collection of packages with methods that allow users to
operate the New Relic APIs. What the end-user code looks like, or how it
behaves is entirely out of scope here from my perspective.

OK, that sounds like a client to me as well. Mostly a low-level client interface with few (if any) abstractions on top. Understanding the intended scope will help me figure out (a) what to expect over the longer term, and (b) what kinds of things I should think about contributing back vs vending as a separate package.

Are you able to discuss anything around the conditions under which this project would graduate from a Community Project to a Community Plus Project? (Which gains: “Support requests can be made through Github, Community, and Ticketed Support channels, depending on the service level associated with the New Relic account.”)

It sounds like a matter of committing a small team to a customer SLA. I don't
know what the future holds on this point. Is there anything in particular
you're looking for here?

Frankly, it's being able to use my super-duper, ultra-platinum, really expensive support package to help me work through issues faster. I'd like to be able to open a support ticket and have them be more prepared to help me when I'm trying to track down an issue that's happening between the client and the API. This weekend we ran into issues, and the first thing out of their mouth was "we don't support that".
I've worked on the front-lines of developer tooling at infrastructure-related companies before, working directly with customers about their issues using our open-source software. I understand that a balance has to be struck with regard to resources and availability, etc. New Relic, Inc. seems to have a documented set of support tiers and their descriptions (which I appreciate). But knowing my own needs, I'm wondering if there are plans to keep this project's formal support where it is, or if there are plans to move it up a notch along with shipping a 1.0.0.
I'm not asking for a definitive answer beyond what you've already given me — thank you, by the way — but I wanted to submit this as enterprise customer feedback into whatever that discussion looks like. These are things that I'm thinking about as I interact with the products, services, and code from New Relic, Inc.
Thanks!

We can discuss a 1.x as a team and see what the right course of
action is. Is
there a concern with the version being pre 1.x that you are able to
share?

Only that, in terms of semantic versioning, pre-1.0.0 simply means
that there is no discernible software contract in-place yet. This
means that the code I write today may not work tomorrow (more or
less). As you explain yourself, you do it "to remain nimble" which I
understand as a developer, but the counter-argument is that the
nimbleness for you comes at the cost of reliability for me.

Just keep in mind that a 1.x doesn't mean we won't break things.  It
just means that we'll communicate through the release of a 2.x that we
have done so, which I think you would find acceptable given your
interpretation on semver (which also seems to align with ours).

On behalf of enterprise customers, I look forward to a stable and
supported 1.0.0 release (meaning that I get to use my super-duper,
ultra-platinum, really expensive support package for this project)
where backwards-compatibility guarantees are a thing, and there are
other bits of software contract that I can rely on.

Understood.  Note that if you use our other projects, you are already
likely relying on this project, though perhaps not directly which is
probably more of your concern.

Do you intend to adopt semantic versioning as a software contract,
and if so, which things are in/out-of-bounds? (e.g., versions of
Go, versions of TLS, TLS ciphers, will they apply to the whole
repo or by-package?)

We currently adhere to semantic version for all of our releases and
we
release the client as a single "atomic" release. The version bumps
reflect
change since the prior release.
With regard to TLS support, I would expect that services would
constrain the
TLS support far more than this project.
I'm seeing posts like this, for example.
https://discuss.newrelic.com/t/january-tls-updates-apis-and-browser-apm/88869
For Go versions, probably v1.13+ is a reasonable constraint.
#474 to follow up.

It's great to hear that the project views itself as being
semantically-versioned… but that's not written down in any obvious
places (e.g., README), and the reality is that most software project
still have not adopted semver, so I (as a consumer) can't assume
such a thing.

Understood.  I would caution you against making any assumptions of
stability based solely on a version number.  Many projects operate for
years without ever releasing a 1.x  Take Terraform for the nearest
example.

But semantic versioning only addresses backwards-compatibility — and
even then, only addresses the compatibility of some parts and not
others. It's not a silver bullet. If, in the future, all New Relic
endpoints suddenly expected TLS 1.3 or HTTP/3 or something else that
doesn't impact function signatures, are they in-scope, or out of scope
for the client API? Do you bump major version, minor version, or patch
for such a change?

This may not be a great example since I don't think we would suddenly
make changes that would affect the wide spread of agent versions in very
tricky places spread globally, and certainly without notice and
coordination.  But to follow the train of thought here, as long as the
underlying Go packages supported the protocols required, then there
should be no impact to users of this project.  If there were a code
change required for us to support a new protocol, then we would version
the release according to the significance of the change.  I think that's
pretty standard practice.  Said another way, if there isn't a code
change required for this project to support the protocols in question,
then there isn't something to release.

It sounds like a matter of committing a small team to a customer
SLA. I don't
know what the future holds on this point. Is there anything in
particular
you're looking for here?

Frankly, it's being able to use my super-duper, ultra-platinum, really
expensive support package to help me work through issues faster. I'd
like to be able to open a support ticket and have them be more
prepared to help me when I'm trying to track down an issue that's
happening between the client and the API. This weekend we ran into
issues, and the first thing out of their mouth was "we don't support
that".

If you're having issues with the client and API, please file any bugs
you find the associated project. We'll mention your scenario to the
proper parties to help prevent these sorts of interactions in the
future.

I've worked on the front-lines of developer tooling at
infrastructure-related companies before, working directly with
customers about their issues using our open-source software. I
understand that a balance has to be struck with regard to resources
and availability, etc. New Relic, Inc. seems to have a documented set
of support tiers and their descriptions (which I appreciate). But
knowing my own needs, I'm wondering if there are plans to keep this
project's formal support where it is, or if there are plans to move it
up a notch along with shipping a 1.0.0.

We have no plans to raise the support tier of our projects at this time.
As for a 1.x, this project is less than a year old, and so I think we've
got a few months before we figure out what a 1.x means for us.
I'll close this out, but hopefully I've answered your questions and
clarified the purpose of this project.  As always, let us know if you
have any other questions.
Cheers

Just keep in mind that a 1.x doesn't mean we won't break things. It just means that we'll communicate through the release of a 2.x that we have done so, which I think you would find acceptable given your interpretation on semver (which also seems to align with ours).

Understood. A major version bump signals backwards-incompatible changes.

Understood. I would caution you against making any assumptions of stability based solely on a version number. Many projects operate for years without ever releasing a 1.x Take Terraform for the nearest example.

That's correct. Again, semantic versioning is not a silver bullet. But Terraform also signals backwards-compatibility guarantees in other ways. They treat the minor as the major at this stage of their development.

But semantic versioning only addresses backwards-compatibility — and even then, only addresses the compatibility of some parts and not others. It's not a silver bullet. If, in the future, all New Relic endpoints suddenly expected TLS 1.3 or HTTP/3 or something else that doesn't impact function signatures, are they in-scope, or out of scope for the client API? Do you bump major version, minor version, or patch for such a change?

This may not be a great example since I don't think we would suddenly make changes that would affect the wide spread of agent versions in very tricky places spread globally, and certainly without notice and coordination. But to follow the train of thought here, as long as the underlying Go packages supported the protocols required, then there should be no impact to users of this project. If there were a code change required for us to support a new protocol, then we would version the release according to the significance of the change. I think that's pretty standard practice. Said another way, if there isn't a code change required for this project to support the protocols in question, then there isn't something to release.

Makes sense. Different organizations reason about this differently, so understanding how New Relic reasons about these types of things is valuable to understand.

If you're having issues with the client and API, please file any bugs you find the associated project. We'll mention your scenario to the proper parties to help prevent these sorts of interactions in the future.

I know, and I do. 😄
But sometimes there's a need to work with this group as well as official New Relic support, and there are times when the customer ends up having to be the go-between. While I'm not looking to place blame, I think it needs to be acknowledged that this happens sometimes, and I'd be interested in seeing if this is something that can be smoothed-out.

But knowing my own needs, I'm wondering if there are plans to keep this project's formal support where it is, or if there are plans to move it up a notch along with shipping a 1.0.0.

We have no plans to raise the support tier of our projects at this time. As for a 1.x, this project is less than a year old, and so I think we've got a few months before we figure out what a 1.x means for us.

Appreciate the honesty here. Thank you.

I'll close this out, but hopefully I've answered your questions and clarified the purpose of this project. As always, let us know if you have any other questions.

Certainly. Thank you again.


Remove references to rhods, change to odh

Do we need to update the references in quickstart.ts file as well ?

That name is created by odh-manifests.

/lgtm


"Enter" key has no effect in Lepiter class comments

"Enter" (i.e. inserting a newline) doesn't seem to work in Lepiter class comments. Workaround: press ctrl+enter.

Fixed in: https://github.com/feenkcom/lepiter/commit/5a78598fd8c1aaef34f323e55cec99b3e6834edc


[add] sanitize control chars

Coverage increased (+0.002%) to 82.871% when pulling ea77cc5d31211ad6e0a32e12cc5500d2c2de221f on sunny4381:sanitize-control-chars into 096adff69785074882788908aa33e29a9c88224f on shirasagi:master.


DPL-185 [BUG] - If we create a library from the samples tab it should not appear in the pools tab, especially if it is un tagged (C=3, V=3)

Describe the bug
If we create a library from the samples tab it should not appear in the pools tab, especially if it is un tagged. Do we need to separate into separate library ‘inboxes’?

Libraries tab: Single untagged libraries, a library that contains a sample with 1 tag, individual components from the pool/new tab. As it already is now
Pools tab: Only multiplex libraries generated from the pool/new tab get listed.

RT Ticket Number
If applicable
To Reproduce
Steps to reproduce the behaviour:

Go to page '...'
Click on button '...'
See error

Expected behaviour
What was expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

Windows or Mac?
Browser Chrome, Firefox, Safari or other?
Browser version (use 'About' to look up)?

Additional context
Add any other context about the problem here.

Merging into: https://github.com/sanger/traction-ui/issues/685

Main issues here are:

Pools page should allow editing of untagged unplexed librairies
Pools page should build confidence about editing single-plexed libraries.


Accept CherryPy accepted_queue_size parameter; print service config

Superseeds #9200
Support accepted_queue_size as defined by the DBS configuration file. Also print the configuration arguments.
Deployment changes are like this: https://github.com/dmwm/deployment/pull/771

It pass the unit tests now, however I still have to test it in my VM and make sure the new parameter gets set in the cherrypy.config.
@yuyiguo once you're done with your tests, can you quickly test these changes as well? Thanks

I confirm it works for WMCore/REST based services (ReqMgr2 etc).
WebTools still need to be validated, used by DBS.

@yuyiguo this one would require some quick tests from your side as well. However, since the REST package has already been tested, if you prefer I can get this merged and you test it once we cut a WMCore tag. Please let me know.

test this please

Same here, DBS needs to make sure it's working as expected.


Exitcodes

New exitcode system:

All commands will now exit with a code
dev-debug will display this code

The codes are a follows:
Pass: Code 0: This code is returned when all is well.
ON SCREEN: [ OK ]
LOGFILE: PASS
Fatal: Code 1: Fatal errors occur when LGSM is prevented from completing its task. e.g it was unable to start a server.
ON SCREEN: [ FAIL ]
LOGFILE: FATAL
Error Code 2: An error occurs when LGSM can complete its task however something went wrong. In many cases LGSM will attempt to resolve errors itself.
ON SCREEN: [ ERROR ]
LOGFILE: ERROR
Warning: Code 3: Warnings happen when there is something mis-configured or not setup correctly. LGSM may still work but not do as expected
ON SCREEN: [ WARN ]
LOGFILE: WARN
Info: No code: Useful infomation about what LGSM is currently doing
ON SCREEN: [ INFO ]
LOGFILE: INFO
Update functions:

now updates changed files rather than just deletes the functions dir.

Improved script logging
Updated travis tests
Various bug fixes

What a merge !

haha i know. Lots of commits on this one. I found it to be quite a complicated issue to resolve


Proposal: DEV Mode

Right now, development is sort of slow with templ because each change requires my entire application to be recompiled. For example, changing a class on a div requires 5 seconds before I can see it in my browser.
I would suggest having a "DEV mode" e.g. templ generate --watch --dev-mode
In this mode, instead of fully generating the static template code, some parts of the code are generated in the filesystem. This way, a full rebuild is not required each time something in the template changes.
I understand that this is difficult in reality since the templ code interfaces with the Go code, but I think there is a way to make this work.

The template is split into "static strings" and "go code".
Anytime part of the "go code" changes, then a full rebuild is required.
The static strings are put in a separate file where they are read from each time. This can be modified without needing the application to be rebuilt.

If it will be too complex to maintain both rendering modes, they could be combined such that in dev mode, the filesystem is read each time, but in prod mode the static strings are embedded with //go:embed

Great idea, and great ideas on the implementation too - it sounds quite practical.
I think that two generation modes would work best, since otherwise we'd have to have the concept of a "StringProvider" - something to look up the values of strings by their integer IDs so that we could swap implementation between dev and prod. Having a StringProvider would harm runtime performance, since we'd go from pushing a string constant, to making a virtual function call, but having two generation modes isn't too painful.
The change would be in this part: https://github.com/a-h/templ/blob/ddb1610a81627f5c9c524bb66877477f401e4ecd/generator/generator.go#L1280-L1294
We'd have to add a mode to the generator struct at https://github.com/a-h/templ/blob/ddb1610a81627f5c9c524bb66877477f401e4ecd/generator/generator.go#L55 and possibly add a Strings []string field to it. When we generate the file in dev mode, instead of loading the string directly, the generator would have to write out some code that requests a string by its id - for example, templ_var_1, err := templdevmode.GetString("./{relative_path}/name.templ", templ_templateHash421, 1).
Since the generator adds strings to the Strings slice, in dev mode, the templ generate command can be updated to write them to disk (maybe as {template_name}.templdev so they can be added to .gitignore/.ignore files and/or deleted), and the GetString function can load them from disk on every render.
To avoid messing about with disks at all, the templ LSP could start a server, and the web app could connect to it when it's in dev mode. The templ LSP already compiles templates on basically every keypress, so it could compile the Strings slice. It also gets a notification when "save" is pressed in the editor, so it could push a reload event back to any apps that are connected.
To detect if extra Go code has been added which should force a complete reload, a hash of the template would need to be calculated and stored in each template. The hash could be as simple as printing the overall structure of the template file with all the HTML taken out, and running that through SHA256.
if { x == y} {
  for i := 0; i < 10; i ++ {
  }
}

Maybe it's crossing the streams a little, but if the hash changes and therefore, we need a regenerate, in dev mode, maybe the templ hot reload middleware could render a web page that lets you click "re-generate", where it runs the templ generate command for you, and restarts itself (it could grab os.Args and find out what the command line flags were/are).
I guess the main question would be whether this would really result in faster application dev. It wouldn't be great if the extra complexity didn't have a meaningful payoff in performance.
These are just ideas at the moment... I think that having a written-up design that we all agree on would be a good start as per https://github.com/a-h/templ/blob/main/CONTRIBUTING.md

Writing out a more structured proposal now, and I think this --dev-mode should be combined with --watch

--watch is only used during development
--dev-mode is not very useful if the files are not being watched
Ideally, we want to "cleanup" after the dev mode ends. So, when the --watch command receives the end signal, it should cleanup the static string files and generate the templates for production. This way, a user does not even have to run another command to generate the production templates.

About integrating with the LSP, I would prefer to avoid that because I think this should be able to work without the LSP.

Improved proposal in #340
Let me know if I should add more details


password protected settings

One can always use external app in order to secure the setting on his installed android apps (including traccar client), however if would be better if this option is integrated within the client itself.

Need advice, if this is possible with the current version.
SharedPreferences sharedPreferences = getPreferenceScreen().getSharedPreferences();
//Fading preferences for address - IP
Preference address = getPreferenceManager().findPreference("address");
address.setEnabled(false);
this code example above did not work, I am trying to hide all the settings from the app screen.

It should work. Where did you put the code?


Add attributes for Format derive to use Debug2Format on specific fields

I often have structs or enums where most fields impl Format, but a few third-party types do not. It is a pain to have to manually impl Format for the whole type when only one field doesn't work. I added an attribute that lets you override specific fields to use Debug2Format or Display2Format like so:
#[derive(defmt::Format)]
pub enum Error {
    Serial(serial::Error),
    Timeout(us_timer::TimeoutError),
    Serde(#[defmt(Debug2Format)] serde_json::Error),
    ResponseTooLarge,
}

Looks really good! Thank you @mattico!

Since I am not super proficient with macros I'd like @jonas-schievink to take a quick look before merging.

Great to see this, thanks!
bors r+


How to pre-commit in Docker Development

Description
It is clear that pre-commit cannot work inside Docker containers and it can only work with git stored on the local machine since its not in a shared volume with the containers. Therefore, it should be noted that anyone who uses this cookicutter with pre-commit already generated by default in every project, should start using pre-commit into their general workflow.
Checklist:

[ ] I've made sure that tests/test_cookiecutter_generation.py is updated accordingly (especially if adding or updating a template option)
[x] I've updated the documentation or confirm that my change doesn't require any updates

Rationale
Fixes #3086

You shouldn't install everything from local.txt.  Instead, the docs should say "to use pre-commit, you should have pre-commit installed globally"

Good idea. I've reworded it so it should be installed as part of a prerequisite.

Thanks for the clarification!


Navigation inside "Add to meeting" wizard broken if no choice exists

If you enter data which does not match any user in the wizard and click "Next", the wizard automatically skips step 2 and goes directly to step 3. If you then click "Back", it goes back to step 2 and presents an empty page. If you then click "Back" and "Next" again, the same problem occurs. The empty "Choice" page should be skipped in every direction.

To avoid confusion: This issue is about the meeting-side participant creation wizard (specifically the option to reference pre-existing accounts).
It has nothing to do with the organization-side account-add-to-meetings.component!


Importing user certificates

Hello, I wanted to try motm with lagrange:
gemini://illegaldrugs.net/cgi-bin/motm/boards
But when registering, it generates and outputs a certificate for me, that I have to use as client certificate after. It’s not clear how to do this with lagrange.

Currently adding existing certificates requires some manual work. It's explained in the Help document ("Importing existing certificates").
You'll need to copy and paste the certificate and the private key into two new files. The certificate file should be named "something.crt" and the key file is "something.key". When you launch Lagrange, it checks for new files in the idents directory and adds them as Identities.
It would be great to have an automated import feature, though, for this kind of provided certificates.

In v1.1 it will be as easy as pressing ⌘⇧I or Ctrl+Shift+I on the page where the certificate and key are shown. The new Import Identity dialog can also handle crt/key pasted from clipboard or drag-and-dropped files.

In v1.1 it will be as easy as pressing ⌘⇧I or Ctrl+Shift+I on the page where the certificate and key are shown. The new Import Identity dialog can also handle crt/key pasted from clipboard or drag-and-dropped files.


Fix for floating pinned persistent header

SliverGeometry in updateGeometry() method does not respect minExtent from Sliver Delegate. Fix for #11222

I signed it!

I signed it!

again

I believe to un-grump the CLA bot you'll need to force-push a new commit with the email address in the commit author field matching one that you've signed the CLA with. :(
Something like this:
https://stackoverflow.com/questions/3042437/change-commit-author-at-one-specific-commit

This needs detailed comprehensive tests.

@Hixie ok, will have a look into testing. @eseidelGoogle I changed author in commit (my second commit in PR) but looks like I need to do PR again to pass CLA bot =(

This change should be applied to both floating/pinned and just pinned headers.

To clarify by testing I meant automated unit tests.

@nonameden Are you planning on doing the tests or should we take this PR over? (either way is fine, just trying to decide if we should leave the PR open in the meantime)

@Hixie sorry, it was busy week at my job, I was planning to do it next week.

Sounds good! No rush!

@nonameden I'm going to take over this patch and write a test for it. Thanks for your contribution!

Thank you @Hixie
I've played with test, but almost gave up with position detection for my slivers
Here the gist with test: https://gist.github.com/nonameden/5ac7b8c129e8ab9ede17fef2f8f0106b

Thanks, you can see what I came up with here: https://github.com/flutter/flutter/pull/11996
I found that I didn't need to change the scrollExtent line, can you elaborate (e.g. comment on that PR) about what doesn't work if that line isn't changed?
Also if there's anything else you think I should test don't hesitate to let me know on that PR.


python311Packages.python-docs-theme: rename from python_docs_theme

Description of changes
part of #245383

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
[ ] 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.

Result of nixpkgs-review pr 265377 at 56b570d6 run on x86_64-linux 1

2 packages built successfully:

python310Packages.python-docs-theme
python311Packages.python-docs-theme

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

4 packages built:

python310Packages.python-docs-theme
python310Packages.python-docs-theme.dist
python311Packages.python-docs-theme
python311Packages.python-docs-theme.dist


chore/change-required-to-default-props

Related issue

null
Scope of work

changed all required props to the default value, because is safety way than require in UI library
Screenshots of visual changes
null
Checklist

[x] I followed composition rules for my component
[x] I tested the component in most common device sizes (can be tested in Storybook from viewport addon in top menu)

If we change this behavior (=no more required props), then we should ensure that the components work with the default values out-of-the-box.
This is not the case for e.g. SfBullets. It will throw an Error because if total is 0 (new default value), the v-for loop in the template will not work when rendering this component and the error it throws (index out of range because there is computed value, subtracting 1 from total which leads to "-1" which is not a valid starting point for v-for) is much harder to figure out for the user than Missing required prop: "total".
IMHO if a component really needs a prop to be rendered properly and if there is no useful default value (like for total), it should stay required wdyt? @przspa


Remove tab size from suggested settings.

Introduced in https://github.com/nvarner/typst-lsp/issues/318
I don't think any extension should change the tabsize. A large reason for tabs over spaces is the freedom to change the visual size.
I guess most people prefer the same size for tabs in all languages, so there prefered size is already set.

This configuration only sets the default tab size, so user settings should override this. (If you aren't actually able to override it, please open an issue to let me know.)
I think this is a good default. My preferred style does depend on the language I'm writing, and to my understanding, 2 spaces is the closest Typst has to a standard right now. This default also makes it easy for new users to create and edit files that follow the most common style. For users with other preferences, it should be possible to set those globally in VS Code to overwrite the default.
Given evidence that users in general would prefer this default not be set, or some documentation that setting it is bad practice, I'll reconsider. Otherwise, I plan to leave this setting as is.


Support running on a local zip file

Right now I can validate my plugin after it is released, but I can't integrate the linter into my ci/cd workflow because it requires a published GitHub release to work.
I'd love to be able to specify a command line like this:
ptr-lint --file DiscordTimestamp-x64.zip https://github.com/neilenns/DiscordTimestamp
and have the linter use the local file to run the linting rules. Then I could add this as a step to my ci/cd and release workflows in GitHub and catch errors before they make it into main.
Thinking about it a bit, I believe the following linting rules would have to automatically skip (perhaps with a logged info message indicating that):

PTRUN1202 (hash check, there'd be no published hash at this point)
PTRUN1202 (package missing, it would only have the one package to check instead of both)

I did some initial messing around with this in a branch, using System.CommandLine to process the command line options. I didn't get much farther though since it started to require some deeper changes to the rules and how the file gets loaded and I'm not really familiar with the code.

I did make more progress on this today, but am currently blocked by GitHub rate limiting me when running. Too many F5s in a row I guess 😅

Ok, after digging into this a bit more, I keep finding other places where changes would have to be made and it's kinda getting bigger than I expected. I thought it was all good, then I realized ReadmeRules looks directly at the one in the repo instead of the one locally on disk. Not sure if there's others I would encounter.
The branch is updated with my current progress. It's... ok? It's not really usable yet though for a ci/cd workflow.

Ok, well... it works. I think? If you have a few minutes, take a peek and let me know your thoughts. Still feels kinda hacky.

I'd love to be able to specify a command line like this:
ptr-lint --file DiscordTimestamp-x64.zip https://github.com/neilenns/DiscordTimestamp

I would like to keep it simple and support both cases without command parameters:
ptrun-lint https://github.com/hlaueriksson/Community.PowerToys.Run.Plugin.Install
ptrun-lint c:\Users\Henrik\Downloads\Install-0.1.0-x64.zip
ptrun-lint ./Install-0.1.0-x64.zip

We need to validate if the arg is an URL or a file path.

I did some initial messing around with this in a branch, using System.CommandLine to process the command line options.

I already use Spectre.Console and it has support for CLI:

https://spectreconsole.net/cli/getting-started

If we need to parse command line arguments, I would pefer to use Spectre.Console.Cli.

I did make more progress on this today, but am currently blocked by GitHub rate limiting me when running. Too many F5s in a row I guess 😅

I think we should add support for PATs, to avoid the API rate limiting.
I did something similar here:
https://github.com/hlaueriksson/Community.PowerToys.Run.Plugin.Install/blob/3a2ae81561dfb50fdcc9e9133807de7831f2731c/src/Generator/GitHubClient.cs#L46

ptr-lint --file DiscordTimestamp-x64.zip https://github.com/neilenns/DiscordTimestamp

The URL to the repo should be available via the Website in plugin.json in the zip file.
I would like to get the README from the GitHub API, and not read the file system.
A use case is downloading a package from some repo and then lint the zip file.
Rules that should not run on zip files:

ReleaseRules
ReleaseNotesRules
PackageChecksumRules

Maybe we need two different Workers for this?

I would like to get the README from the GitHub API, and not read the file system.

The problem with that is it would be running against the readme in main, not the readme in the current pull request. The goal is to validate what is in the pull request to make sure it is compliant, before it makes it into main and then a release.

I did make more progress on this today, but am currently blocked by GitHub rate limiting me when running. Too many F5s in a row I guess 😅

I think we should add support for PATs, to avoid the API rate limiting.
I did something similar here: https://github.com/hlaueriksson/Community.PowerToys.Run.Plugin.Install/blob/3a2ae81561dfb50fdcc9e9133807de7831f2731c/src/Generator/GitHubClient.cs#L46

Yeah, I added a command line parameter to specify the PAT in my branch. Works great, it just sets the variable you already had set up.

I would pefer to use Spectre.Console.Cli.

Ah cool, didn't notice that. I'll go mess around tomorrow with it.

The problem with that is it would be running against the readme in main, not the readme in the current pull request. The goal is to validate what is in the pull request to make sure it is compliant, before it makes it into main and then a release.

Ok, I understand.
Maybe we can use the git metadata (commit hash) from the DLL, if SourceLink is enabled.
The assembly metadata attribute is called SourceRevisionId.

I sent you a Discord friend request ☺


Infineon OPTIGA Trust X

The change adds support for the Infineon XMC4800 IoT developer board augmented with an OPTIGA Trust X crypto element.

/bot run checks

/bot run checks

https://amazon-freertos-ci.corp.amazon.com/job/master/job/custom_ide/41/console

/bot run checks

/bot run checks


Fix lessphp composer vendor (using 2.0.0)

Update composer.json to have the concrete5 lessphp vendor name. Autoload wasn't working properly because it was looking for the original vendor, fixed here https://github.com/concrete5-forks/less.php/commit/eebead5849b7dd21f450905007cd65a385b894e3 but wasn't being applied.

This is fine, I don't think this will really change anything though.


scalatest: upgrade to 3.2.1

Contributor Checklist

[x] Did you delete any extraneous printlns/debugging code?
[x] Did you specify the type of improvement?
[x] Did you state the API impact?
[x] Did you specify the code generation impact?
[x] Did you request a desired merge strategy?
[x] Did you add text to be included in the Release Notes for this change?

Type of Improvement

code cleanup
dependency update

API Impact

none

Backend Code Generation Impact

none

Desired Merge Strategy

merge

Release Notes
n/a
Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (1.2.x, 1.3.0, 1.4.0) ?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

It would be great  if someone with write access could merge this PR and close #1828


[bug]: The   ‘npx shadcn-ui@latest init’ cannot be executed on the company network. How can I init it offline?

Describe the bug
Describe the bug
Tried installing with the command, "npx shadcn-ui@latest init". But it keeps throwing the following error.
FetchError: request to https://ui.shadcn.com/registry/styles/index.json failed, reason: connect ECONNREFUSED <IP_ADDRESS>:443
at ClientRequest. (file:///Users/equallyai/.npm/_npx/125ee17d583c4e03/node_modules/node-fetch/src/index.js:108:11)
at ClientRequest.emit (node:events:518:28)
at TLSSocket.socketErrorListener (node:_http_client:495:9)
at TLSSocket.emit (node:events:518:28)
at emitErrorNT (node:internal/streams/destroy:169:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:82:21) {
type: 'system',
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT',
erroredSysCall: 'undefined'
}
Failed to fetch styles from registry.
Affected component/components
None
How to reproduce
npx shadcn-ui@latest init
Codesandbox/StackBlitz link
No response
Logs
None

System Info
wind11 node:v20.11

Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues

@captainyufei I tried asking ChatGPT,
you could follow these, and all the source code is available so you could try to self-host shadcn if you want to.
The solution involves pre-downloading the necessary files and dependencies in an environment with internet access, transferring them to the offline environment, and setting up the project locally

I guess it's not a bug specific to Shadcn. It would have been better if you had asked in the discussions section.

The issue was resolved by the system administrator, who granted me full access and added the necessary certificate. After that, the issue was resolved.

The issue was resolved by the system administrator, who granted me full access and added the necessary certificate. After that, the issue was resolved.

can you tell me about the necessary process


Markdown Docstrings

Based on Rescript 11 branch.
Docs adapted to work with the new doc parser.
Some things still need to be resolved, like section headings, they are not working as intended (doc parser displays them instead of the actual function documentation.
I'll mark this as ready once I'll proofread the entire docs.

All the functions now have markdown docs, and they are displayed correctly in the IDE.
Unfortunately, section titles (Create, Iterate, etc) had to go since it was confusing Rescript compiler.
Interlinking between docs does not work (for now), I'll try to address this in a separate PR.


Adding nextTick information in v-for

A lot of time user might want to do some action after v-for is finished rendering. This can be done via Vue.nextTick function. I think vue docs can explicitly point this out to user.

I'll be more than happy to do the edit if collaborators think that this is a valid request

Thanks for the suggestion! 🙂 Could you give an example of the kind of use case you'd like to see better described?

In my case i was dynamically adding data to a v-for which would have scrolled my input element out of view. So to scroll input into view i had to use nextTick so as to make sure that the loop is rendered beforehand.

Thanks for explaining. 🙂  In this case, the updated hook should have been able to solve the same problem, so I don't think there's actually a need to add nextTick this early.

Thanks for pointing that out. I was actually looking for something like updated hook, but ended up using nextTick.
But, will we know what got updated in the hook? I know it's not required in my case but just out of curiosity.

No, in cases where you need to react to some specific changes, I recommend watchers.

oh! Right. Thanks for the help.


No way to set crawl depth for crawler

Currently crawler only crawls links of depth level 1. That means if you give homepage link (homepage.com) it will only crawl direct links from that homepage and it will not crawl links that are located in homepage.com/news/sports-data ---> if there is for example "more info" link located here it won't be crawled.

@matijaparavac  We're building our scraper engine, which will soon be available in the Crawl4ai library. We started by focusing on a robust, fast, and asynchronous approach to crawl a single page effectively. This was part of our roadmap—to ensure we could properly generate data, handle various situations, execute JavaScript, and navigate all the nuances of crawling a page. Now, we’re developing the scraper itself, which features a customizable graph search algorithm with various parameters.
Right now, you can simulate crawling by fetching one page and, from the results, get a list of all internal and external links. You can then use a task queue to crawl as many of those links as you like. That’s one approach you can take for now, but we'll be releasing the full scraper engine soon!

Great to hear this! Thanks!


Finding a value in an array

I started using nlohmann::json today (thanks for it) and I wanted to check whether a certain value is contained in an array: I used find(). It compiled but it does not work.
#include <json.hpp>
using json = nlohmann::json;
int main(void)
{
	json j({"hello", "world"});
	std::cerr << j << "\n";
	std::cerr << (j.find("hello") != j.end()) << " expecting 1\n";
	for (const auto &i: j)
		if (i == "hello")
			std::cerr << "found it while iterating\n";
    return 0;
}

it gives
["hello","world"]
0 expecting 1
found it while iterating

Reading json.hpp I saw that find() is often done with a key. What is the expected behavior of finding on an array?

Just looking a bit more - I think I found it ;-)
from json.hpp:
 iterator find(typename object_t::key_type key)
 {
     auto result = end();

     if (is_object())
     {
         result.m_it.object_iterator = m_value.object->find(key);
     }

    return result;
}

Yes, the documentation of find is also clear about this:

Finds an element in a JSON object with key equivalent to key. If the element is not found** or the JSON value is not an objec**t, end() is returned.

To find elements in an array, you can use std::find.

What confused me was the silent returning of find() giving me end(). Naively I'd expect an error somehow. I'm still discovering your style but would an assert not be the better solution for newbies like me. Please enlighten, it'll help me understand better your design decisions.

The design decisions are difficult, because we basically try to "merge" the behavior of a std::vector and a std::map. As find as member function is only available to std::map and I do not want to accidentally degrade to linear complexity, there is no member find for arrays.
I understand that silently returning end() is confusing. Maybe changing this to an exception could be a change for the 3.0.0 release.

Should the semantics be changed to throw in this case?

"The basic_json object represents a json object" is a precondition of calling this function.
Is there a general philosophy on what to do in the case of a precondition violation?

@gregmarr In similar issues where we mix the behavior of std::map and std::vector we have the range of

defining the missing behavior
throw an exception if called on the "wrong" value type

In this case, there is just a comment that when called on anything but an object, find will always behave as if nothing was found.
As searching in an array is rather expensive, I tend to throw an exception in this case.

I just ran into the same problem with
size_type size() const noexcept

for a string-element. I accidently took it for the length of the string.

@pboettch This is also clearly documented.

After some thinking I agree with you. find() and size() work as they should and my expectations were wrong. I even can explain what mislead me: The slogan: "What if json was part of modern C++?". I understand that json is trying to integrate as much as possible with std::-container and algorithms, but no. It actually means what is says: how would we design json to be a container class in std::?
As all cases are documented and well described, one just has to learn it.
You can close this "issue" from my point of view. I would have rather discussed this on a mailing list than in an issue. Thanks again for your work.

I may be going against the consensus here, but for someone who does not read documentation unless I can't get API to work to my expectations, returning end asserts "I searched for the value, and it's definitely not there", whereas throwing domain_error says misuse!

I don't see a major issue with allowing find on arrays. If there is a note regarding the complexity impact that would be nice. I am picturing a structure with maybe 2-10 items in it, each referencing some id, and upon each we want to see if it contains x and y. Writing a search function by hand for each of these isn't convenient, but it's exactly what we want. Having it return end is confusing. Having it throw an exception isn't useful. There is already a heavy slant of usability over performance, but even the implementation of this shouldn't add much if any impact.
A little bit of this is my wish for more convenience methods in the standard so take it for what you will :v: Since json isn't an array nor a map having a perfect correspondence to one or the other depending on the subtype to me at least doesn't make a lot of sense.

So basically this is what I wrote in https://github.com/nlohmann/json/issues/399#issuecomment-268208449:

@TurpentineDistillery proposes to throw when find is used with an array ("throw an exception if called on the "wrong" value type")
@whackashoe proposes to actually search in an array and return an iterator and ("defining the missing behavior")

Any more opinions?

Keep it as it is? If you change find()-behavior on an array, why not change size()-behavior on a string?
Find is for finding a json-object identified by a key (AFAIU), in an array of strings there are no keys.

Right - I totally forgot about the signature of find.
I'm not sure about the semantics of size()...

My remark comparing a possible size()-behavior change to a find()-behavior-change was to show, IMHO, the current design is correct. It is strict and defined as one should expect.
I think my initial problem would have not appeared here if I had found an example of how to find a value in a json-array - for example in the  README.

Any of the associative containers (set, multiset, etc) are allowed conversion to a json array which do support find in their native type. Without allowing the ability to search once this type has been included then converted to an array it seems like a (albeit partial) lossy abstraction, instead this could be a additive abstraction which either gains or keeps equal the search method from the convertible types. Certainly either way leaving it with end being returned seems wrong.

So throwing seems to be the best way to go.

I don't insist on throwing. If find worked on vectors in linear time, that would be perfectly reasonable as well.
as for size(), I think it should return the same value as if implemented as
    size_t size = 0;
    for(const auto& jj : my_json) {
        size++;
    }
    return size;

Good point. I use the semantics of the Container requirement: std::distance(begin(), end()).

Letting find throw would definitely not be in congruence with the STL (std::map::find also returns end). But then again, having a find member on an array in the first place is not in congruence with the STL! So my opinion is that there shouldn't be such a member. My suggestion is to let people use std::find like you would have to when using std::arrays or std::vectors, unless there's some way a ::find member can be implemented that is less thatn O(N) (which I don't think there is).

@louwers
size_t std::string::find(char c, size_t pos = 0) const noexcept;

@TurpentineDistillery D'oh! Thanks for pointing that out. Lets try that again: the STL does't implement a find method for sequence containers. Because JSON values can be both a sequence container (an array) and an assosicative container (objects), I'm inclined to agree that a find method may be sensible, but it's debatable.

The find function is used quite frequently to check if a key is present in an object. Removing it would make that check quite cumbersome.

On a related note, if the behavior of find gets changed to throw or do the work, then behavior of count() should probably also change respectively.

The more I think about it, I tend to leave everything as is. The semantics of find is: "give me an iterator to the element with the given key, or end() if no such key exists". When called on a type other than an object, I think we satisfy this contract and return end() regardless of the key, as in: "You asked whether this integer 42 has an element with key "foo"? Well no it doesn't, here is an end() iterator". I think this is nothing we need to handle with an exception, because we can "answer" the question without any effort.
The same holds true for count(). "How many entries with key "foo" has this Boolean?" - "0.".

Another thing: I totally forgot the table in https://nlohmann.github.io/json which lists the behavior of all combinations of member functions known from the STL and the different JSON value types.

I'm late to the discussion, but I've also just burned myself on this. I agree with people who think that .find() should throw if called on a non-object. Just like .get<> throws when called on null json.

Changing the behavior now would be a breaking change, and I do not thing such a change would be for the better.

After searching online for about 10 minutes, I still can't figure out how to determine if a JSON array contains an element.
json j;
j["new"]["key"]["value"] = {"another", "list"};
std::cout<<j["new"]["key"]["value"].is_array()<<std::endl;
std::cout<<j["new"]["key"]["value"].contains(std::string("another"))<<std::endl;

prints
1
0

what do I do here?

contains() always returns false when called to JSON values that are not objects. Indeed, std::find is the right approach.


escapeshellarg() has been disabled for security reasons

My company's hosting provider disables this function (escapeshellarg) by default for security reasons.
This causes phpwkhtmltopdf to fail since the arguments aren't correctly escaped.
Is there a way we could check whether this function exists first, and if not use some kind of polyfill function?
Thanks in advance!

Sorry, but we can not build in workarounds for scenarios like this as we would have to implement an alternative version for basically any PHP function.
As a sidenote: Why your provider thinks this helps for safety is above my head. In fact you could argue that code without escapeshellarg() is potentially more insecure as it opens the door to inject harmful commands via your shell args. Maybe it's time to find a better provider?


Fix indentation in polygon schema

There was some bad indentation in the previous schema which prevented deployments.

Sorry for the unnecessary ping, I thought that this needed a review to be merged.


[Device Support Request] OWON Technology Inc. PC321,need more information to be displayed

Is your feature request related to a problem? Please describe.
OWON Technology Inc. PC321, Energy Monitor support needed please.
Device can be paired @ZHA, but appeared entity shows only shows "Instantaneous Demand" ( 0x0400，Instantaneous energy consumed summation of the 3 phases)
According to the manufacturer's documents, Please help adding 0x0000 current summary delivered (Current summation delivered of the 3 phases);
This data can be now obtained through the following process:
integration-ZHA-Owon Pc321 device-manage clusters- clusters "metering" (0x0702)- current_ summ_ delivered (id: 0x0000)- get zigbee attribute
more info can be shown would be great, thanks!
Describe the solution you'd like
More monitoring data is needed
Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4412, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.0: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x000d",
"in_clusters": [
"0x0000",
"0x0003",
"0x0702"
],
"out_clusters": [
"0x0003"
]
}
},
"manufacturer": "OWON Technology Inc.",
"model": "PC321",
"class": "zigpy.device.Device"
}
Additional context
Add any other context or screenshots about the feature request here.
Manufacturer's documents can be obtained here:
https://github.com/froggyfly/pc321-zigbee/blob/main/PC321zigbee.docx

I would also like to get the CurrentSummationDelivered from a device (to have it reported in Home Assistant).
Documentation: http://<IP_ADDRESS>//en/telecharger.php?fichier=um_zmeter.pdf
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=1, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4281, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=0, maximum_outgoing_transfer_size=160, descriptor_capability_field=<DescriptorCapability.ExtendedSimpleDescriptorListAvailable|ExtendedActiveEndpointListAvailable: 3>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0501",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x0009",
        "0x0702"
      ],
      "out_clusters": []
    }
  },
  "manufacturer": "CLEODE",
  "model": "ZMETER/E",
  "class": "zigpy.device.Device"
}

Is there some other implementation that we could start from?
I am appending this Request here as I suppose that the implementation is going to be pretty similar.

Its one fix for power measuring in HA beta that is coming in the 2012.10 so testing the beta or waiting for the GA.

Reoppening as it still an issue on zha

Hi @froggyfly , I have one of these devices and, like you, it's only reporting a single power & energy value, each the summation of the three phases.
Did you ever manage to reconfigure to obtain each phase independently?
Thanks.


3.6.0: Set active in navigator or dropdown results in error with ODBC OpenEdge(DataDirect) driver

I get the error catalog not found.
Got this info from the progress support
I found out that DBeaver is generating the incorrect SQL command:
set catalog "PUB"
instead of the correct SQL command:
set schema 'PUB'

That's odd.
DBeaver do not use "set catalog" statement for any of standard database drivers.
Could you post error stacktrace (from Error Log view).


Add .well-known/security.txt, fixes #1372

Add .well-known/security.txt as recommended in https://securitytxt.org/
This adds a simplified direct link to the text about how to
report vulnerabilities, to make it easier to get there immediately.
Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

This is a pretty trivial change, and in production just adds a constant public file. So I'm just going to merge it now.


has anyone implemented the  LIS2HH12 using SAME5 from Microchip?

I am new to LIS2HH12 and using SAME54 MCU.   Was hoping to get a sample of the code using the i2c from SAME54.
thank you

I don't know the i2c details of SAME54. What you have to do is writing the platform routines (read, write, delay), but I cannot help you on your specific platform.
/*  Initialize mems driver interface */
stmdev_ctx_t dev_ctx;
dev_ctx.write_reg = platform_write;
dev_ctx.read_reg = platform_read;
dev_ctx.handle = &SENSOR_BUS;

Thank youOn Jul 24, 2023 5:51 AM, Armando Visconti @.**> wrote:
I don't know the i2c details of SAME54. What you have to do is writing the platform routines (read, write, delay), but I cannot help you on your specific platform.
/  Initialize mems driver interface */
stmdev_ctx_t dev_ctx;
dev_ctx.write_reg = platform_write;
dev_ctx.read_reg = platform_read;
dev_ctx.handle = &SENSOR_BUS;
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>


failed to initiate panic within clone child

panic is not working correctly within the child of clone. The following code
fn main() {
    let mut stack = [0u8; 1024 * 1024];
    let child = Box::new(|| {
        panic!("child");
    });
    let pid = clone(child, &mut stack, CloneFlags::empty(), Some(Signal::SIGCHLD as i32)).unwrap();
    wait::waitpid(pid, None).unwrap();
    panic!("parent");
}

produces the following output
thread 'main' panicked at 'child', src/main.rs:191:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
fatal runtime error: failed to initiate panic, error 5
thread 'main' panicked at 'parent', src/main.rs:195:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Note, fatal runtime error: failed to initiate panic.

rustc 1.35.0 (3c235d560 2019-05-20)
libc 0.2.55
nix 0.11.0

clone(2) is notoriously difficult to use correctly.  This isn't a Nix problem.  In order to fix it, you're going to need to grok how Linux processes work, what clone does, and how Rust prints a backtrace.

In order to fix it, you're going to need to grok [...] how Rust prints a backtrace.

Indeed, I've been digging in that direction already. Though, sadly with little success so far. I found this in the context of a side-project where I can live with broken backtraces. Nonetheless, I thought it would be worth raising an issue. It seems likely that others will encounter this problem as well.

clone(2) is notoriously difficult to use correctly. This isn't a Nix problem.

I'm pretty new to Rust, so please forgive me if I'm misreading. But, quoting this project's README:

For many system APIs, Nix provides a safe alternative to the unsafe APIs exposed by the libc crate. This is done by wrapping the libc functionality with types/abstractions that enforce legal/safe usage.

clone is not marked as unsafe and there are no documented caveats. If nothing else, it seems to me that clone should be marked as unsafe, or at least document the Rust specific caveats. I.e. broken backtraces, possibly other aspects of the runtime.
It could be argued that a safe clone wrapper should shield users from such difficulties. At least those related to the language runtime.

I've played with this a bit and catch_unwind lead me down an interesting path. I've come up with the following implementation of clone (based on that in nix) that handles panic better. (No more "failed to initiate panic" and this also removed a segfault I was getting after a panic before). This clone is still wildly unsafe, though. With CLONE_VM it segfaults, otherwise it leaks parent's memory in the child, and probably lots of other issues that I'm not aware of. Anyway, thought I'd share it in case it's useful to anyone.
use libc::{c_int, c_void};
use nix::{errno::Errno, sched, sys::signal::Signal, unistd::Pid, Result as NixResult};
use std::panic;

pub fn clone<F>(
    callback: F,
    stack: &mut [u8],
    flags: sched::CloneFlags,
    signal: Option<Signal>,
) -> NixResult<Pid>
where
    F: FnOnce() -> isize + panic::UnwindSafe,
{
    extern "C" fn c_callback<F>(optf: *mut c_void) -> c_int
    where
        F: FnOnce() -> isize + panic::UnwindSafe,
    {
        let optf = optf as *mut Option<F>;
        let optf = unsafe { &mut *optf };
        // Option::take is used to avoid "cannot move out of borrowed content".
        match optf.take() {
            Some(f) => {
                // catch_unwind will print the panic message and optionally the backtrace.
                let r = panic::catch_unwind(|| f());
                // Return exit code 1 on panic.
                r.unwrap_or(1) as c_int
            }
            None => unreachable!(),
        }
    }
    let combined = flags.bits() | signal.map(|s| s as c_int).unwrap_or(0);
    let res = unsafe {
        let ptr = stack.as_mut_ptr().offset(stack.len() as isize);
        let ptr_aligned = ptr.offset((ptr as usize % 16) as isize * -1);
        libc::clone(
            c_callback::<F>,
            ptr_aligned as *mut c_void,
            combined,
            &mut Some(callback) as *mut _ as *mut c_void,
        )
    };
    Errno::result(res).map(Pid::from_raw)
}

clone is not marked as unsafe and there are no documented caveats. If nothing else, it seems to me that clone should be marked as unsafe, or at least document the Rust specific caveats. I.e. broken backtraces, possibly other aspects of the runtime.

This is actually a matter of some disagreement within the Rust community.  Rust's safeness isn't a shield from the operating system doing weird things.  For example, on Linux if you open /dev/mem and scribble on it, your program will crash.  But that doesn't mean that open and read should be unsafe.  clone is in a similar boat.

It could be argued that a safe clone wrapper should shield users from such difficulties. At least those related to the language runtime.

There already are safe wrappers of clone.  They're called fork and pthread_create.  If neither of those satisfies your needs, then you're probably doing something pretty unusual.


[Feature Request]: Add support for zyx tiles served by WFP's HDC

Provide a clear and concise description of what you want to happen.
WFP's HDC will begin to support zyx tiles soon (timing TBC). This is a big change as we'll want to deprecate WMS requests to HDC in favor of tiles on cloud storage. However, we should continue to support WMS requests for non-HDC requests.
We may have already addressed this via https://github.com/WFP-VAM/prism-app/pull/728. @ericboucher, what do you think?
@valpesendorfer - I am not yet sure how dates will be attributed in the storage location. Has this been spec'd yet?
Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already.
No response

Nothing is spec'd yet - we're fairly early in the development, but it would be good if we can discuss a few aspects in a meeting before we start going into a specific direction.
Tagging @kirill888 for his reference


More Markdown Magic! Readme Improvements

Includes stylistic improvements and a revised description with improved spelling and grammar.

Last of changes made for today


Why is style check done locally, but not in github actions?

https://github.com/MBkkt/cppformlang/runs/1081779937

Sorry, copy-paste problem, but it would be nice if cmake-format runs for all files in the repository

Glad to hear you resolved it!
CMake-format should actually run for all (C++ / CMake) files in the repository.
Can you perhaps give some more details on what didn't work?

@TheLartians I think fix-cmake-format doesn't work for CPM.cmake, but check-cmake-format works, may be for include or something
Try change CPM.cmake and do fix-cmake-format

Are you using the newest version of the starter? In an old version we had excluded CPM.cmake, but this has been changed recently. If you're test/CMakeLists.txt contain an exclude pattern for CPM.cmake, you could try removing that. I'd also recommend updating to the newest version of CPM.cmake by running
mkdir -p cmake
wget -O cmake/CPM.cmake https://github.com/TheLartians/CPM.cmake/releases/latest/download/get_cpm.cmake

in the project root.

I think yes, I am using the same as in the your template current master

That's strange then, for me in does format all files 🤔

I use arch linux may be problem in this


Add executor

This adds the executor functionality paradigm that I like. The idea being that you can add an execute method to your structs and it will allow the parse command to also execute the command related to the struct that is used for the provided command. Would love some feedback / ways to improve if the current implementation is not understood / liked. Using from my own fork for now.

Friendly ping regarding this PR. If I don’t hear anything I’ll consider this abandoned by next week.


Fixes #19

Before only a few fields were cleared when a Metablock Header was encountered
However the btype_l may refer to an array of different dimension than the one for this metablock.
This resets everything to the ground state.
Also added a test to demonstrate the behavior (test used to fail but now passes)

@danielrh You're amazing, Daniel! The fix looks correct, and, yes, it's entirely reasonable to start with a fresh metablock when a new metablock header starts.
I didn't do a good job at all testing for cases with multiple metablocks, and that debt's now asking to get paid.
Thanks a lot for finding, reporting, and fixing this, Daniel!