Add new root query button in queries browser

In the new queries browser is not possible to add a new root query. Currently, if you add a new query it must be a child of the root query. We want to have the possibility to add a new query that not a child of any other query.
Like shown in the below image is not possible to add a new root query:

It would be nice to have a button to add a new root query like this:

it was closed by #182


mlforecast: Allow to calculate the full Conformal Prediction Distribution

Description
It would be really interesting to be able to get the full conformal production distribution (equivalent of the CDF).  A bit like this article describe: https://valeman.medium.com/how-to-predict-full-probability-distribution-using-machine-learning-conformal-predictive-f8f4d805e420, or this one which is CatBoost specific but still: https://towardsdatascience.com/another-conformal-way-to-predict-probability-distributions-fcc63e78680d
Not sure how easy to implement it would be for time series though.
Use case
It would be really helpful for downstream simulation to optimize decision making.

Crepes seems to be the only package that implement Conformal Predictive System used to calculate full conformal prediction distribution: https://crepes.readthedocs.io/en/latest/crepes_nb_wrap.html#Conformal-Predictive-Systems-(CPS)

Hey @EtienneT, sorry for the late reply. We store the conformity scores on the _cs_df attribute, which has the scores by serie and horizon. You can get it with the following:
import lightgbm as lgb
from datasetsforecast.m4 import M4, M4Info
from mlforecast import MLForecast
from mlforecast.utils import PredictionIntervals

# load data
group = 'Hourly'
info = M4Info[group]
horizon = info.horizon
await M4.async_download('data', group=group)
df, *_ = M4.load(directory='data', group=group)
df['ds'] = df['ds'].astype('int')

# train
n_windows = 4
n_series = df['unique_id'].nunique()
fcst = MLForecast(
    models=[lgb.LGBMRegressor(verbosity=-1)],
    freq=1,
    lags=[24],
)
fcst.fit(df, prediction_intervals=PredictionIntervals(n_windows=n_windows, h=horizon))

# extract scores
lgb_scores = fcst._cs_df['LGBMRegressor'].to_numpy().reshape(n_windows, n_series, horizon)
lgb_scores.shape
# (4, 414, 48)

We use these scores to compute the intervals here https://github.com/Nixtla/mlforecast/blob/55e9b504ba37fa4dbb7fd092bfd4654540eb5da7/mlforecast/forecast.py#L62-L69
Please let us know if this helps.


feat(batch): support batch limit push down

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Resolve https://github.com/risingwavelabs/risingwave/issues/13506#issuecomment-1825061006
Use BatchPushLimitToScanRule to pass limit to the scan, so that RowSeqScanExecutor can return early and avoid prefetching in this case.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Maybe we can remove the Scan::chunk_size later.
https://github.com/risingwavelabs/risingwave/blob/648f985c7011247be2f423ca45f5b5433dccbd9f/src/frontend/src/optimizer/plan_node/generic/scan.rs#L47

I want to deprecate the chunk_size, since it is used only for batch queries. It should never cause compatible issues.

After this, should we have another test for concurrent scan in daily tests such as sysbench? cc @lmatz

After this, should we have another test for concurrent scan in daily tests such as sysbench?

We can add it, what's the specific setting you want?

After this, should we have another test for concurrent scan in daily tests such as sysbench?

We can add it, what's the specific setting you want?

select * limit no longer works, maybe sth more others which can still trigger scan, such as select * from t where id < 1, which is supposed to return a small amount of data, but we still need to scan it without index.

After this, should we have another test for concurrent scan in daily tests such as sysbench?

We can add it, what's the specific setting you want?

select * limit no longer works, maybe sth more others which can still trigger scan, such as select * from t where id < 1, which is supposed to return a small amount of data, but we still need to scan it without index.

how about running  select count(*) from sbtest1 concurrently.

After this, should we have another test for concurrent scan in daily tests such as sysbench?

We can add it, what's the specific setting you want?

select * limit no longer works, maybe sth more others which can still trigger scan, such as select * from t where id < 1, which is supposed to return a small amount of data, but we still need to scan it without index.

how about running select count(*) from sbtest1 concurrently.

LGTM, this is what user expects.


Day summary/icon incorrect

Describe the bug
This morning I noticed a few instances where the day icon and summary aren't being calculated correctly. Examples below (cut out any details that weren't relevant in the day block):
Today
  "icon": "clear-day",
  "summary": "Clear",
  "precipIntensity": 0,
  "precipIntensityMax": 0,
  "precipProbability": 0.05,
  "precipAccumulation": 0,
  "cloudCover": 0.4,

Tuesday
  "icon": "clear-day",
  "summary": "Clear",
  "precipIntensity": 0.0161,
  "precipIntensityMax": 0.0468,
  "precipProbability": 0.44,
  "precipAccumulation": 0,
  "cloudCover": 0.38,

Wednesday
  "icon": "partly-cloudy-day",
  "summary": "Partly Cloudy",
  "precipIntensity": 0.0326,
  "precipIntensityMax": 0.2587,
  "precipProbability": 0.22,
  "precipAccumulation": 0.0698,
  "cloudCover": 0.37,

Expected behavior
Today and Tuesday should show Partly Cloudy as the summary and icon. Wednesday should show Clear as the summary and icon.
Actual behavior
Today and Tuesday shows Clear as the summary and icon. Wednesday shows Partly Cloudy as the summary and icon.
API Endpoint
Production
Location
Barrhaven, Ontario
Other details
This isn't related to the icon issue but I noticed that Tuesday has a precipIntensity above zero whereas the precipAccumulation is 0. I thought it would be above zero in this case.
Troubleshooting steps

[X] I have searched this repository and Home Assistant Repository to see if the issue has already been reported.
[X] I have read through the API documentation before opening this issue.
[X] I have not included my API key anywhere in my issue.
[X] I have written an informative title.

@alexander0042 Been a few hours since my post and am still seeing the issue. It only seems to happen when cloudCover is close to 37.5% as there is another day with 66% cloudCover and it works without any issues.

@alexander0042 Still seeing issues with this the next day. Also noticed one day that should show the rain icon but isn't for some reason.
Tuesday
  "icon": "clear-day",
  "summary": "Clear",
  "precipIntensity": 0.0373,
  "precipIntensityMax": 0.2392,
  "precipProbability": 0.78,
  "precipAccumulation": 0.21650000000000003,
  "precipType": "rain",
  "cloudCover": 0.33,

Wednesday
  "icon": "partly-cloudy-day",
  "summary": "Partly Cloudy",
  "precipIntensity": 0,
  "precipIntensityMax": 0,
  "precipProbability": 0.09,
  "precipAccumulation": 0,
  "precipType": "snow",
  "cloudCover": 0.32,

@alexander0042 Sorry for the repeated pings on here but this is still an issue. A bit annoying to have to double check the daily details in case the icon/summary shown is incorrect.

I'm 90% sure I've isolated what's happening here! The icon is calculated from the 4 am to 4 am times; however, the averaged values (which is what you're seeing for cloud cover and the like) are calculated from 00:00 to 00:00. So while they align almost all of the time, they can be off.
I think the easiest fix here is just to change everything to the 4:00 reset. I can't really imagine a use where someone would want the 00 times, and that data could always be calculated from hourly if need be

Yeah, I'm not entirely sure how exactly Dark Sky did it. I was looking in the Wayback Machine yesterday when I was checking to see how they did their Dry/Humid text and did notice multiple instances of the summary and icon being different (rain icon but summary showed Partly cloudy throughout the day).
Having the text summaries and #49 would definitely help when they get added though it may not be for a while. Not sure what a good short-term solution would be. I did have a thought about adding fields for this but I'm not sure we need more fields similar to the min/max and high/low temperature fields.

For now, I think we just leave things as we are and release 2.4.0 as is. This is a bit of an edge case, so not a super high priority, but very much worth keeping in mind


Do not split single values in SplitTooLongLine transformer

Closes #436

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (d94dcb3) 97.03% compared to head (82a1c59) 97.03%.

:exclamation: Current head 82a1c59 differs from pull request most recent head 94fd04b. Consider uploading reports for the commit 94fd04b to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #487   +/-   ##
=======================================
  Coverage   97.03%   97.03%
=======================================
  Files          45       45
  Lines        4147     4150    +3
=======================================
+ Hits         4024     4027    +3
  Misses        123      123

Impacted Files
Coverage Δ

robotidy/transformers/SplitTooLongLine.py
97.86% <100.00%> (+0.03%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


✘ [ERROR] near "��": syntax error at offset 0 when running wrangler d1 migrations apply with Prisma generated migration (on Windows, using Powershell)

Bug description
I get an error while trying to apply my migration with wrangler.

I'm using the guide here.
Here is the log:
wrangler-2024-04-02_17-44-57_583.log
Here is the migration file (as txt instead of sql):
0001_create_user_table.txt
How to reproduce
I run the following command in terminal:
npx wrangler d1 migrations apply prisma-demo-db --local
Expected behavior
No response
Prisma information
schema.prisma
generator client {
  provider = "prisma-client-js"
  previewFeatures = ["driverAdapters"]
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

Environment & setup

OS: Windows
Node.js version: v18.20

packages:
{
  "name": "nuxt-app",
  "private": true,
  "type": "module",
  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "npm run build && wrangler pages dev ./dist",
    "postinstall": "nuxt prepare",
    "deploy": "npm run build && wrangler pages deploy ./dist",
    "build-cf-types": "wrangler types"
  },
  "dependencies": {
    "@prisma/adapter-d1": "^5.12.0",
    "@prisma/client": "^5.12.0",
    "nuxt": "^3.11.1",
    "vue": "^3.4.21",
    "vue-router": "^4.3.0"
  },
  "devDependencies": {
    "@cloudflare/workers-types": "^4.20240329.0",
    "nitro-cloudflare-dev": "^0.1.4",
    "prisma": "^5.12.0",
    "wrangler": "^3.43.0"
  }
}

Prisma Version
prisma                  : 5.12.0
@prisma/client          : 5.12.0
Computed binaryTarget   : windows
Operating System        : win32
Architecture            : x64
Node.js                 : v20.6.1
Query Engine (Node-API) : libquery-engine 473ed3124229e22d881cb7addf559799debae1ab (at<EMAIL_ADDRESS>Schema Engine           : schema-engine-cli 473ed3124229e22d881cb7addf559799debae1ab (at<EMAIL_ADDRESS>Schema Wasm             : @prisma/prisma-schema-wasm 5.12.0-21.473ed3124229e22d881cb7addf559799debae1ab
Default Engines Hash    : 473ed3124229e22d881cb7addf559799debae1ab
Studio                  : 0.499.0
Preview Features        : driverAdapters

You can also work around this by using another "terminal" than Powershell, for example Cmd or Git bash.
The underlying cause here is that using command > foo.sql in Powershell (the default in VS Code) by default creates a UTF16 LE file, instead of the usual UTF-8 one. Pretty weird choice by Windows and Powershell, and there is no simple way to change that. wrangler d1 migrations apply does expect a UTF-8 file though, and can not read the initial characters of the created file - and throws that error.
(This more popular issues is caused by the same problem: https://github.com/prisma/prisma/issues/17558)
We are currently evaluating what we can do in this situation to avoid this or help you realize the problem without having to open an issue here.

👋🏼
I'm not a Windows user, though I used Windows to reproduce and could feel the pain of this issue.
Good news 🎊 -> there is now an easy way to avoid this since https://github.com/prisma/prisma/releases/tag/5.12.1 just released a few minutes ago.
I added to migrate diff an output option -o or --output.
Example usage for an initial migration:
npx prisma migrate diff --script --from-empty --to-schema-datamodel ./prisma/schema.prisma --output ./schema.sql

By letting the Prisma CLI do the writing, it avoids the problem of using the redirect with PowerShell ✅
And I think it's a useful option to have in general too 🙌🏼
Let us know what you think if you have any feedback 💚


Schema Evolution parameter on awswrangler.s3.to_csv method

Hi, good morning.
I have a doubt if the method awswrangler.s3.to_csv has schema_evolution parameter support. I don't see as Parameter in documentation but if I see the dataset parameter definition, this is mentioned.

dataset (bool) – If True store as a dataset instead of ordinary file(s) If True, enable all follow arguments: partition_cols, mode, database, table, description, parameters, columns_comments, concurrent_partitioning, catalog_versioning, projection_enabled, projection_types, projection_ranges, projection_values, projection_intervals, projection_digits, catalog_id, schema_evolution

Is posibble use schema_evolution on awswrangler.s3.to_csv method ?
PD: I am using AWS Data Wrangler version 2.9
Thanks,
Regards

Hi @raulmeza, no, at the moment schema evolution is not available for wr.s3.to_csv, however this looks like a good moment to add it.


Agent.WorkingDirectory appears not to be writable when run from inside a container

Not exactly sure why, but when I run Cake from within a Linux Container (Ubuntu / .NET Core) as part of an Azure Pipelines build, the directory pointed at by Agent.WorkFolder (aka TFBuild.Environment.Agent.WorkingDirectory ) is not writable, such that Cake.TFBuild.Module.TFBuildReportPrinter.WriteToMarkdown is failing to create the tasksummary.md file.
This results in the following error:
========================================
Default
========================================
##[debug]Processed: ##vso[task.logdetail finishtime=02/25/2019 05:00:15;progress=100;result=Succeeded;id=3f293bfc-27b1-42cf-af56-139f503340c8;]update
##[debug]Processed: ##vso[task.logdetail finishtime=02/25/2019 05:00:15;progress=100;state=Completed;result=Succeeded;id=0ffa0556-53ab-4a01-8f8a-c7dd226e3a15;]update
Error: One or more errors occurred. (Access to the path "/__w/tasksummary.md" is denied.)
	Access to the path "/__w/tasksummary.md" is denied.
##[debug]Exit code 1 received from tool '/bin/bash'

(I wasn't having this problem when I was building in a non-container Ubuntu hosted agent)

See comments in https://github.com/Microsoft/azure-pipelines-agent/issues/2122. Looks like Agent.WorkFolder is not the best place


Spellcheck integration

Is your enhancement related to a problem? Please describe.
https://github.com/crate-ci/typos/blob/master/docs/github-action.md exists as a decent option for us to consider integrating on its own across projects, but perhaps having that as an additional feature in the repo automator set of tools might be useful?  I'm not certain if using the Typos action and adding another check to our repos is best or adding additional run time to the repo-automator check is best, so something to consider here but in any case ideal to run a spellchecker against the existing codebases to cleanup and then catch any newly introduced spelling errors.
cc: @szepeviktor for the idea in https://github.com/10up/safe-redirect-manager/pull/407
Designs
No response
Describe alternatives you've considered
cc:
Code of Conduct

[x] I agree to follow this project's Code of Conduct

Thanks for opening the issue, @jeffpaul. I have looked into this and also experimented with the typos action on one of our repositories. Based on my findings, I believe that directly using the action on our repository is a clearer approach (we just need to add one job here). Please let me know if you'd like me to set it up across all of our OSS project repositories.
Thank you!

I help you with configuring typos


Cog.add_command, .remove_command, etc.

Summary
see title.
What is the feature request for?
disnake.ext.commands
The Problem
There's currently no proper way of dynamically adding/removing commands from cogs, other than directly messing around with internal fields like __cog_commands__.
The Ideal Solution
New methods like Cog.add_command, .remove_command, as well as complementary ones for slash/user/message application commands.
The Current Solution
modifying __cog_commands__, which isn't documented
Additional Context
suggested here: https://canary.discord.com/channels/808030843078836254/913779868985090089/1058180711095484416

I shall take a look

After some discussion, I don't think we'll be adding this; there are too many moving parts already in the way cogs work, and this would likely only complicate things.
Cog command callbacks are instance methods, meaning they should accept a self parameter, which makes defining such a method outside of a cog unintuitive.
Currently, the proper solution to the original issue of grouping commands would be using extras as outlined here: https://canary.discord.com/channels/808030843078836254/913779868985090089/1064287849467367555 (more context around that message too).


Are we going to use Redux?

Probably not, but I'll leave that up to Julian (if time is willing).

I've created a Redux branch using boilerplate code from this project: https://github.com/LeoLeBras/react-native-redux-starter-kit/tree/next
I'm working on converting our existing code to Redux-style components and will submit a pull request with explanations so that we can develop future components in Redux.


[Gene Rails] Budget display title

Currently, when displaying a gene for a price range, we show just the gene title:

Force shows it as a category also:

In the data we get from Metaphysics, we get a price range. e.g. 50.00 - 5000.00:

And the designs only show us an example of "Minimalism under $10,000":

So the question is, what title text do we show?

Do we always pick the upper limit and say "Gene X under Upper Limit of Price Range", in the example of a price range of 50 - 5000, "Black and White Photography under $5000".
Do we show a price range?

cc @katarinabatina

@katarinabatina bump

Should display genes that the user follows
We should make a label to denote the category and if a user is following that category

Since users may not necessarily have a great memory of categories they followed or that artsy even has categories of artworks, we should add labels above these categories to add clarity.

Ok. @katarinabatina - comments make sense! Adding an extra label etc.. very doable, just hoping we can fit it in timewise (because it deals with a few edgecases). I'm still on Eigen currently and am hesitant to context switch, but will aim to get this in.
Is it ok that this falls slightly lower on the priority than some other polish required for V1? Or are you very adamant? (this helps me prioritise :))

Lower in priorities is ok!
Sent with thumbs,
Katarina Batina
Product Designer
Artsy.net

On Sep 20, 2016, at 10:49 AM, Maxim Cramer<EMAIL_ADDRESS>wrote:
Ok. @katarinabatina - comments make sense! Adding an extra label etc.. very doable, just hoping we can fit it in timewise (because it deals with a few edgecases). I'm still on Eigen currently and am hesitant to context switch, but will aim to get this in.
Is it ok that this falls slightly lower on the priority than some other polish required for V1? Or are you very adamant? (this helps me prioritise :))
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Unassigning as I'm not necessary on this one I think, if ok.

@katarinabatina still relevant?


Apply #[doc(cfg(feature = "..."))] banners in docs

This PR adds the #[doc(cfg(..))] banners for all #[cfg(..)] attributes. The result can be seen here:

This is achieved by providing a new config option called syn_enable_doc_cfg, that is either set by the build script, if a nightly compiler is used, or from docs.rs directly (via crate metadata).
Closes #731.

I will address the issues and force-push once I'm done.

I gave this a try locally with RUSTDOCFLAGS='--cfg syn_enable_doc_cfg' cargo doc --all-features and... it's not great.
I am happy with how the message turns out at the top of the doc page of a single type or function, as seen in the screenshot at the top of this PR.
But our index page becomes extremely noisy; I wish there were a way to not show all of these:

And inheriting the same note onto every public field seems silly in our use case:

I plan to leave some feedback on the doc_cfg tracking issue and defer this PR until the feature is in better shape. Thanks anyway @jfrimmel!


Use SVOX repository at AOSP due to DMCA takedown

point this to Google

cause can't sync with your default xml file


Bug CSS in JS with !important rule

Bug report
Describe the bug
can't get CSS in JS with !important working
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

Create a div with some style
<div style={{ margin: "200px",              textAlign: "center",              width: "100px",              height: "100px",              border: "1px solid black",              background: "red !important"            }}          >            some text          </div>
result

when i'm inspect element, style rule for background is gone.

if i remove the !important it works

Expected behavior
style rule is working with !important
System information

OS: Windows 10
Browser : Chrome Version 72.0.3626.109
Version of Next.js: 8.0.0

This is an issue in React: https://github.com/facebook/react/issues/1881

You could use github.com/zeit/styled-jsx for this though.

Thanks for the confirmation


upate filter config provider to return reference wrapper of filter factory cb

Signed-off-by: wbpcode<EMAIL_ADDRESS>Commit Message: upate filter config provider to return reference wrapper of filter factory cb
Additional Description:
In the previous ecds implementation, we will always create a temp copy of FactoryCb which results in uncessary memory allocations and atomic operations (copy and destroy shared pointer in the FactoryCb).
Risk Level: Low.
Testing: N/A.
Docs Changes: N/A.
Release Notes: N/A.
Platform Specific Features: N/A.

If this is for some special design reason, feel free to close this PR.

LGTM. This was an oversight (some factories are expensive to copy).

cc @yanjunxiang-google

/assign @htuch
Please take a final pass


ARP Entries: Azul.Zulu.13.JRE version 13.35.51

Pull request has been automatically created using Add-ARPEntries

Removed DisplayVersion because it matches https://github.com/microsoft/winget-pkgs/pull/74980


Enhancements to parseRepoBranch()

What GitHub issue does this PR apply to?
Resolves #106
What changed and why?
Used indexOf() method to find indexes of "/ " and ":" in the string parameter passed in parseRepoBranch() function.  If both the indexes for "/ " and ":" are greater than 0 and index of "/ " is greater than index of ":", all is good and no error message is returned.

@sophia-guo - can/should this be merged?


classes in attrs are obliterating classes in selector

v(".foo.bar", { class: "gronk" })
should emit

but instead emits

Yup, I'm going to use classList.add/.remove for non-selector attrs so that we can set and remove classes independently (as long as the sets of dynamic classes are disjoint).


Caution: With tests

This PR updates the with_tests branch to match the latest state of main, and introduces some approval tests for Typescript. I'm not super confident that this set of merges went correctly, so it would be worthwhile checking the state for - particularly - csharp and python. I have validated that the tests build and pass with dotnet test and pytest respectively, but I had to merge a whole bunch of things, and then revert the early "reset to starting position" commit.

Unfortunately I think there is too much mixed up in this PR for me to accept it as it is.  There are also changes in all the other language versions. Can you fix this PR so it's only the typescript subfolder that has updates?

Let me close and have another go. I was trying to bring this branch up to date with all changes on main so that it's easy to maintain in future. Otherwise you'll always need to separately backport changes instead of merging off the main branch.


Game window appears behind window where game was opened (including IDE)

I was unable to find any other bugs quite like this.
Godot version:
3.2.4.beta2 (this does not occur in beta1, implying a possible regression of some kind to me)
OS/device including version:
macOS Catalina v10.15.5, running a GLES3 app.
Issue description:
If I run my game from the editor, the game window itself now appears behind the editor itself - I have to go find it and click on the game icon at the bottom in the program bar to get it to come to the front.
In addition to this, if I'm for instance running my exported game from a folder on my computer, the game appears behind the folder from which I launched it.
I turned off batching to see if that was related, but it is not. I tried several things related to graphics, got nothing, so suspect this is somewhere in the windowing code.
Steps to reproduce:
1: Own a mac (and be sad about it)
2: Start a new project
3: Create a scene, make it the main scene on startup
4: Run the game - game will appear behind Godot
Minimal reproduction project:
This happens with all projects I'm building currently as well as a dummy project that literally just had a single scene with nothing in it, so I suspect it doesn't require a repro project itself. Happy to provide it though if absolutely necessary.

Actually, just noticed this was merged: https://github.com/godotengine/godot/pull/43678 Any relation? Seems like it could be a focus-stealing artifact.
I have discovered a work-around: turn on Always on Top. It's not my favorite setting to use for obvious reasons, but it does work to fix the exact issue mentioned.

#43678 fixed this, this issue is the same as #43675.


[HOLD 297303][$1000] Description inconsistency-description missing in some tasks - inside room

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
There are going to be 3 Users for this test: User A, B and C. User A needs to be a mobile number. User B and C can be email.

Login with User A and create a new workspace. Go to settings > workspaces > new workspace
Invite User B into that workspace.Go to  Workspace > members > invite
Create a room from User A with that workspace in restricted mode.
Inside the room, click on the + button >  Assign task
Add title, description. In the description use anything. (I used www.ebay.com)
After task is created, go inside the task thread and verify if you can see the description from User A and User B. You should be able to
7.. Now, from User A, invite a new person (User C) to the workspace. Go to workspace > members > invite > Search for User C
Once User C has been added to the workspace, he must have access to the room.
From User C: search the room > enter the room> enter the task thread
From User C, verify if you can see the description.

Expected Result:
Description should be visible to User C
Actual Result:
Description was not visible to User C
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.35-5
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/36989786-e253-495c-a693-c27b25c8eb06
https://github.com/Expensify/App/assets/43996225/0939955b-5d0a-4400-8de9-22b63e2e642d
Expensify/Expensify Issue URL:
Issue reported by: @avi-shek-jha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688108522149949
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~017bd23f16e781b3ef
Upwork Job ID:<PHONE_NUMBER>517805568
Last Price Increase: 2023-07-03

I also found that this is reproducible if UserA or UserB logs out and logs back in. This means that the Description update is only stored in Onyx data, and is not being saved in the backend.
I believe that this might be a backend issue.

I can confirm this is a backend issue. The response from the API endpoint GET /api?command=OpenReport doesn't include description field.
https://github.com/Expensify/App/assets/20035221/a5adc377-a021-43f9-b395-ca65dbe3e066

API Response
{
  "onyxData": [
      {
          "onyxMethod": "merge",
          "key": "report_957048967020506",
          "value": {
              "reportID": "957048967020506",
              "reportName": "Go Shopping",
              "type": "task",
              "chatType": "",
              "ownerEmail"<EMAIL_ADDRESS>              "ownerAccountID": 14961964,
              "policyID": "BF04561FB6E76BB5",
              "participants": [
<EMAIL_ADDRESS>              ],
              "participantAccountIDs": [
                  14961992
              ],
              "isPinned": false,
              "lastReadTime": "2023-07-04 13:03:37.709",
              "lastMentionedTime": null,
              "lastReadSequenceNumber": 0,
              "lastVisibleActionCreated": "2023-07-04 09:02:04.043",
              "lastVisibleActionLastModified": "2023-07-04 09:02:04.043",
              "lastMessageText": "",
              "lastActorEmail"<EMAIL_ADDRESS>              "lastActorAccountID": 14961964,
              "notificationPreference": "always",
              "welcomeMessage": "",
              "stateNum": 0,
              "statusNum": 0,
              "oldPolicyName": "",
              "visibility": null,
              "isOwnPolicyExpenseChat": false,
              "isWaitingOnBankAccount": false,
              "lastMessageHtml": "",
              "hasOutstandingIOU": false,
              "policyName": null,
              "hasParentAccess": true,
              "parentReportID":<PHONE_NUMBER>412466,
              "parentReportActionID": "960197497704653573",
              "writeCapability": "all",
              "managerID": 0
          }
      },
      {
          "onyxMethod": "merge",
          "key": "report_957048967020506",
          "value": {
              "lastReadTime": "2023-07-04 13:06:05.948"
          }
      },
      {
          "onyxMethod": "merge",
          "key": "reportActions_957048967020506",
          "value": {
              "5326382277030511836": {
                  "reportActionID": "5326382277030511836",
                  "actionName": "CREATED",
                  "created": "2023-07-04 09:02:04.043",
                  "reportActionTimestamp":<PHONE_NUMBER>043,
                  "avatar": "https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/default-avatar_24.png",
                  "message": [
                      {
                          "type": "TEXT",
                          "style": "strong",
                          "text": "User Main<PHONE_NUMBER>)"
                      },
                      {
                          "type": "TEXT",
                          "style": "normal",
                          "text": " created this report"
                      }
                  ],
                  "person": [
                      {
                          "type": "TEXT",
                          "style": "strong",
                          "text": "+9779841111111"
                      }
                  ],
                  "automatic": false,
                  "sequenceNumber": 0,
                  "shouldShow": true,
                  "lastModified": "2023-07-04 09:02:04.043"
              }
          }
      },
      {
          "onyxMethod": "merge",
          "key": "personalDetailsList",
          "value": {
              "14961992": {
                  "accountID": 14961992,
                  "avatar": "https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/default-avatar_21.png",
                  "displayName": "User One"
              }
          }
      },
      {
          "onyxMethod": "merge",
          "key": "reportActions_5609407657412466",
          "value": {
              "960197497704653573": {
                  "person": [
                      {
                          "type": "TEXT",
                          "style": "strong",
                          "text": "User Main"
                      }
                  ],
                  "actorEmail"<EMAIL_ADDRESS>                  "actorAccountID": 14961964,
                  "message": [
                      {
                          "type": "COMMENT",
                          "html": "Created a task: Go Shopping",
                          "text": "Created a task: Go Shopping",
                          "isEdited": false,
                          "whisperedTo": [],
                          "isDeletedParentAction": false,
                          "reactions": []
                      }
                  ],
                  "originalMessage": {
                      "html": "Created a task: Go Shopping",
                      "lastModified": "2023-07-04 09:02:04.047",
                      "taskReportID":<PHONE_NUMBER>20506
                  },
                  "avatar": "https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/default-avatar_24.png",
                  "created": "2023-07-04 09:02:04.047",
                  "timestamp":<PHONE_NUMBER>,
                  "reportActionTimestamp":<PHONE_NUMBER>047,
                  "automatic": false,
                  "actionName": "ADDCOMMENT",
                  "shouldShow": true,
                  "reportActionID": "960197497704653573",
                  "lastModified": "2023-07-04 09:02:04.047",
                  "childReportID":<PHONE_NUMBER>20506,
                  "childType": "task",
                  "childReportName": "Go Shopping",
                  "whisperedTo": [],
                  "whisperedToAccountIDs": []
              }
          }
      },
      {
          "onyxMethod": "merge",
          "key": "report_957048967020506",
          "value": {
              "lastReadTime": "2023-07-04 13:06:05.948"
          }
      }
  ],
  "jsonCode": 200,
  "requestID": "7e179561ccf49885-KTM"
}

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01d399442e7d0b4557

Ah, looks like you're right.

@thienlnam I'm assigning you since it looks like this is tasks bug. Let me know if I'm mistaken in that!

We're handling this in https://github.com/Expensify/Expensify/issues/297303

@thienlnam should I close this issue then? Since it seems like a dupe?

It seems like we created the internal issue after this was reported so we can keep this open to payout the reporting bonus

Ok sounds good.
@avi-shek-jha can you go ahead and apply to the Upwork job?

@puneetlath Proposal Submitted. Thanks.

Sent the offer @avi-shek-jha. Ping me here once you've accepted and I'll pay it out.

@puneetlath Accepted the offer. Thanks.

Great. Paid!
Going to go ahead and close this out since we have a back-end issue already for this bug. Thanks everyone!


Issue: Grammar #1994

Put in the proposed grammar changes from issue #1994.

In the future, put Fixes #issuenumber somewhere in the description and the issue will automatically close on merge.


Firefox warning: Use nonce-source oder hash-source instead of unsafe-inline for script source.

Firefox warn me that I should nonce-source or hash-source instead of unsafe-inline for script-src.
But I configured script-src as self.
    # signs/verifies all cookies
    signed_cookie:
        names: ['*']
    # prevents framing of the entire site
    clickjacking:
        paths:
            '^/.*': DENY
    # prevents redirections outside the website's domain
    external_redirects:
        abort: true
        log: true

    # prevents inline scripts, unsafe eval, external scripts/images/styles/frames, etc
    csp:
        hosts: []
        content_types: []
        enforce:
            level1_fallback: false
            browser_adaptive:
                enabled: false
            report-uri: %router.request_context.base_url%/nelmio/csp/report
            default-src:
                - 'none'
            script-src:
                - 'self'
            block-all-mixed-content: true # defaults to false, blocks HTTP content over HTTPS transport
            # upgrade-insecure-requests: true # defaults to false, upgrades HTTP requests to HTTPS transport

nevertheless I have a unsafe-inline' in my Content Security Policy:
default-src 'self'; script-src 'self' 'unsafe-inline' 'nonce-...'; style-src 'self' 'unsafe-inline' 'nonce-...'

It just happens in the dev mode if the web_profiler is on. So no problem.

It would be nice if there was mention of this feature in the docs.


More exercise for the pytest local episode

Feedback from 2022-09 was that this was very fast and there was too much time.  We weren't in a rush for the rest, and making it much faster might make it hard for those who are slower.
I suggest adding some advanced exercises to that episode.  For example

--pdb (and anything else that helps with TDD)
Test-driven development (add test first, then add code to make it pass)
Running only certain tests with -k
Fixtures (maybe too advanced/would take too long for anyone who doesn't know it already)
Not capturing stdout with -s (this may be too esoteric but it's one of the things I use often when developing)

We actually plan to mostly skip the local testing exercises in favor for having more time and an actual (not type along) exercise for the CI setup and automated testing. i.e. letting participants set up their own small repo with tests (or rather setting up a repo without workflows that contains a few tests and have them add a new test for a function.

I would rather combine exercises into one block. That episode really misses R examples (#165) and other languages before we add more Python features.


Feature Scan device QR code

there is the possibility to add the QRCode option passing the UIView???
Scan
Device information can be extracted from scanning valid QR code. User of this API decides the camera preview layer frame by providing UIView as parameter. It return single ESPDevice instance on success. Supports both SoftAP and BLE.
ESPProvisionManager.shared.scanQRCode(scanView: scannerView) { espDevice, _ in}

I don't have time to implement this right now but will accept tested pull requests.


[Wayland] Godot doesn't register inputs from graphic tablet on GNOME

Tested versions
Reproducible only in v4.3.dev3.official [36e943b6b], since it's first version that introduced Wayland support.
System information
Fedora Linux 39.20240214.0 (Silverblue), Linux 6.7.4-200.fc39.x86_64, AMD Radeon RX 570 Series, GNOME 45.4 on Wayland session, tablet in use Wacom One Pen Display 13, Forward+ renderer
Issue description
Godot editor with enforced Wayland run/platforms/linuxbsd/prefer_wayland = true completely ignores inputs from Wacom tablet on Wayland session, including clicking and moving with pen. Same happens with running projects with display/display_server/driver.linuxbsd = wayland. With this options turned off, everything works as expected.
Steps to reproduce

Change run/platforms/linuxbsd/prefer_wayland in editor setting to true.
Restart Godot.
Now Godot won't accept any inputs from tablet via pen.

Minimal reproduction project (MRP)
Same could be achieved with running projects.

Create empty project.
Change project setting display/display_server/driver.linuxbsd to wayland.
Add node and attach script:

extends Node

func _input(event):
	print(event.as_text())

It generate properly generates inputs with mouse:
Mouse motion at position ((702, 633)) with velocity ((-0.000042, 0.000042))
Mouse motion at position ((697, 635)) with velocity ((-0.000625, 0.00025))

But moving around and clicking with pen generates nothing.
wayland_input_wacom.zip
Video demonstration with game run with display/display_server/driver.linuxbsd = wayland option:

When cursor is visible and data is printed, that's mouse.
When cursor become invisible, that's when I use pen on tablet.
When display/display_server/driver.linuxbsd = default, everything works fine:

First I move with mouse, then pen, then mouse again and then pen again. In all cases inputs are printed.

I tested Huion H430P tablet without screen, and it also doesn't work. In fact, Godot didn't recognized any inputs from this tablet, including onboard buttons (there 4 in total).

Is there possibility to open some kind of fundraiser to buy tablet for testing?

@Riteo It might be worth trying https://github.com/H-M-H/Weylus with a phone/tablet. Its Wayland support is marked as experimental though.

@Riteo after some embarrassingly long time trying to figure how to compile Godot, I did it, yay!
Here result with display/display_server/driver.linuxbsd = wayland, test project seems to works without any issues on Wacom tablet:

Without this pr it does nothing, as expected:

I can't test this with other tablet (huion that I mentioned earlier) for reasons that it magically vanished in time and space, but since Wacom works, I assume other tablets also will work as expected.
Also, Godot editor itself now works with run/platforms/linuxbsd/prefer_wayland = true.


Tests for the InfluxDB client

... add a step in CI that starts an influxdb container with an endpoint and some data.

Originally posted by @suvayu in https://github.com/TulipaEnergy/TulipaIO.jl/issues/19#issuecomment-2042634233

[ ] Implement a test that runs with EDR but is not included in CI
[ ] Implement a step in CI that spins up an InfluxDB instance, populates with dummy data, and runs the above test against this instance

I can - but frankly, I think my time would be better spent elsewhere for now. These tests will be useful when we get more code relying on this functionality, and it would enable better testing then. But for now, these tests are quite a lot of work to create for what is literally 40 lines of simple code. So I would prefer to defer this work until it becomes more relevant.

@wcoenraads Do you think the first point is also a lot of effort?  I would say if we can address the first one, and leave the more complete approach for later, it is a lot better.

@suvayu Is this still relevant or can I close it unplanned?

Close as superseded by esdl4tulipa


Implement CAB-2619 - New checkbox component

Coverage decreased (-0.9%) to 81.205% when pulling 1b1dd9cdb6366fb0120630404c5d8a5ae816a09c on feature/CAB-2619 into 869f897b5b9fdca216555b3b5fce738842dc6108 on develop.


lib_libvsprintf.c: add Add support for %pB parameter.

Summary

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.
Add LIBC_PRINT_EXTENSION option to control the opening of %p*, which is closed by default

Impact
None. This is a new parameter parsing and does not affect existing parameters.
Testing
pc: ubuntu 20.04,x86, SIM

void orb_info(FAR const char *format, FAR const char *name,
              FAR const void *data)
{
  struct lib_stdoutstream_s stdoutstream;
  struct va_format vaf;

  vaf.fmt = format;
  vaf.va  = (va_list *)data;

  lib_stdoutstream(&stdoutstream, stdout);
  lib_sprintf(&stdoutstream.common, "%s(now:%" PRIu64 "):%pB\n",
              name, orb_absolute_time(), &vaf);
}

order: uorb_listener -n 10 sensor_accel_uncal
out:
Mointor objects num:1
object_name:sensor_accel_uncal, object_instance:0
sensor_accel_uncal(now:57777592500):timestamp:57777591900,x:0.081402,y:0.689530,z:9.897630,temperature:31.253906
sensor_accel_uncal(now:57777632700):timestamp:57777632300,x:0.126893,y:0.792481,z:9.911995,temperature:31.253906
sensor_accel_uncal(now:57777672800):timestamp:57777672500,x:0.055066,y:0.708684,z:9.892841,temperature:31.253906
sensor_accel_uncal(now:57777713500):timestamp:57777713200,x:0.107739,y:0.682347,z:9.861717,temperature:31.253906
sensor_accel_uncal(now:57777754000):timestamp:57777753500,x:-0.040701,y:0.677559,z:9.751583,temperature:31.253906
sensor_accel_uncal(now:57777794200):timestamp:57777793800,x:0.117316,y:0.751779,z:9.797073,temperature:31.253906
sensor_accel_uncal(now:57777834600):timestamp:57777834100,x:0.081402,y:0.732626,z:9.734824,temperature:31.253906
sensor_accel_uncal(now:57777874700):timestamp:57777874400,x:0.062249,y:0.711078,z:9.732430,temperature:31.253906
sensor_accel_uncal(now:57777915000):timestamp:57777914700,x:0.114922,y:0.826000,z:9.742006,temperature:31.253906
sensor_accel_uncal(now:57777955600):timestamp:57777955000,x:0.098162,y:0.756568,z:9.809045,temperature:31.253906

timestamp:57777591900,x:0.081402,y:0.689530,z:9.897630,temperature:31.253906 is B parameter output results

[Experimental Bot, please feedback here]
No, this PR does not meet the NuttX requirements.
Missing Information:

Summary:

Lacks a clear explanation of why this change is necessary.  Is it a bug fix? A feature request?  Provide context.
"uorb info call" is too specific. What is the broader functional area impacted (e.g., logging, debugging, data formatting)?

Impact:

While you state "None," you need to address all impact points.  Even if the answer is "NO," explicitly state it for clarity.
Your provided code snippet seems like it belongs in the "Testing" section.

Testing:

Insufficient detail:

You need to list the specific host operating systems, CPUs, compilers, target architectures, and boards you used for testing.
Provide actual testing logs, not just placeholders.

Unclear what is being tested: The code snippet is not self-explanatory.  Describe the test case and expected results both before and after your change.

Recommendations:

Expand the Summary:  Explain the motivation for adding %pB.  Is there a specific use case or issue it solves?
Complete the Impact Section:  Even if the impact is minimal, go through each point and confirm its status.
Provide Detailed Testing Information:

List all relevant host and target configurations used.
Include complete testing logs demonstrating the issue before your change and the successful outcome after.
Clearly explain the purpose of your test code and the expected results.

By addressing these points, your PR will be more informative and likely to be reviewed and merged more quickly.

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS.
their way to extend the functionality seems quite broken as it prevents us from providing standard %p.
please don't follow the mistake.

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier:
https://www.kernel.org/doc/Documentation/printk-formats.txt

please don't follow the mistake.

Could you give more info why it isn't good?

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: [https://www.kernel.org/doc/Documentation/printk-formats.txt](https://www.%5Bkernel.org/doc/Documentation/printk-formats.txt](https://www.kernel.org/doc/Documentation/printk-formats.txt))

printk is a non-standard linux-internal api, which isn't meant to conform any standards.

please don't follow the mistake.

Could you give more info why it isn't good?

printf("%pS", NULL) should yield something like "0x0S".
besides that, these kinds of extensions are not recognized by the compiler's __format__ attribute.

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: [https://www.kernel.org/doc/Documentation/printk-formats.txt](https://www.%5Bkernel.org/doc/Documentation/printk-formats.txt](https://www.kernel.org/doc/Documentation/printk-formats.txt))

printk is a non-standard linux-internal api, which isn't meant to conform any standards.

please don't follow the mistake.

Could you give more info why it isn't good?

printf("%pS", NULL) should yield something like "0x0S".
besides that, these kinds of extensions are not recognized by the compiler's __format__ attribute.

Ok, @Otpvondoiats let's add an option in Kconfig to control this special format specifier.

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: [https://www.kernel.org/doc/Documentation/printk-formats.txt](https://www.%5Bkernel.org/doc/Documentation/printk-formats.txt](https://www.kernel.org/doc/Documentation/printk-formats.txt))

printk is a non-standard linux-internal api, which isn't meant to conform any standards.

please don't follow the mistake.

Could you give more info why it isn't good?

printf("%pS", NULL) should yield something like "0x0S".
besides that, these kinds of extensions are not recognized by the compiler's __format__ attribute.

Ok, @Otpvondoiats let's add an option in Kconfig to control this special format specifier.

Get

@yamt please review the new implementation which disable the extension by default.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf.
when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)
hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

an alternative approach is to use a non-conflicting modifier/specifier.
it still has a possibility of feature conflicts and has __format__ attribute problems though.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

@yamt hi, Can it be merged?

%pB follow the current/Linux design, and the new option minimize the potential conflict, can we move the optimization to the next phase?

%pB follow the current/Linux design, and the new option minimize the potential conflict, can we move the optimization to the next phase?

what linux design are you talking about? i explained that we were not following what printk does.
my request is not about optimization but conformation to standards.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

@yamt hi, Can it be merged?

i'm against it.

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

@yamt hi, Can it be merged?

i'm 对 it.

Thanks for review

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf?
or all printf families?

also, have you considered a less intrusive approach? https://github.com/apache/nuttx/pull/13536#issuecomment-2370184919

Refere

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

%pB is used to print the structure of the uorb

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

Refere

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

%pB is used to print the structure of the uorb

do you mean, only printf, not snprintf etc?

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR.

Refere

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.
isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

%pB is used to print the structure of the uorb

do you mean, only printf, not snprintf etc?

%pB is in the vsprintf_internal function, all printfs are affected, but currently only uorb is using this function.

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf. If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."
which function is "this function"?
what do you mean by "drawn from printf alone"?
even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".
also, i have already suggested at least two alternative approaches.

i guess the least invasive approach would be something similar to strftime.
ie. have a separate function to create a string representation. (and use printf %s to print it.)

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."
which function is "this function"? what do you mean by "drawn from printf alone"?
even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".
also, i have already suggested at least two alternative approaches.

The strftime method is not suitable for this purpose. It is necessary to apply for space according to the output buffer. In addition, the orb info function is a public function. It will take up a lot of CPU resources to apply for buffers of different lengths. In addition, the printf function itself takes up a lot of CPU resources. Again, buffer printing has been integrated into the sprintf function.

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."
which function is "this function"? what do you mean by "drawn from printf alone"?
even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".
also, i have already suggested at least two alternative approaches.

Our current disagreement is that the %p* type printing cannot be aligned with Linux, and the characters use %pB. Our current disagreement is that the %p* type printing cannot be aligned with Linux, and %pB* (%pBb) can be used as a subset extension.

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."
which function is "this function"? what do you mean by "drawn from printf alone"?
even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".
also, i have already suggested at least two alternative approaches.

The strftime method is not suitable for this purpose. It is necessary to apply for space according to the output buffer. In addition, the orb info function is a public function. It will take up a lot of CPU resources to apply for buffers of different lengths. In addition, the printf function itself takes up a lot of CPU resources. Again, buffer printing has been integrated into the sprintf function.

i wonder why you read my comments very selectively.
how about "implement the functionality in your app using lib_bsprintf and printf as of today,"?

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."
which function is "this function"? what do you mean by "drawn from printf alone"?
even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".
also, i have already suggested at least two alternative approaches.

  Our current disagreement is that the %p* type printing cannot be aligned with Linux, and the characters use %pB. Our current disagreement is that the %p* type printing cannot be aligned with Linux, and %pB* (%pBb) can be used as a subset extension.

i don't know what your png files are about.
i guess they are documentation of linux printk.
printk is not printf.

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."
which function is "this function"? what do you mean by "drawn from printf alone"?
even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".
also, i have already suggested at least two alternative approaches.

  Our current disagreement is that the %p* type printing cannot be aligned with Linux, and the characters use %pB. Our current disagreement is that the %p* type printing cannot be aligned with Linux, and %pB* (%pBb) can be used as a subset extension.

i don't know what your png files are about. i guess they are documentation of linux printk. printk is not printf.

I don't selectively read your comments。
I first disable these extension functions in the printf related functions inside Nuttx to ensure that they are not called in the standard printf, and then consider implementing a new API for this type of extension interface (printk)

I don't selectively read your comments。

ok.
then probably i just don't understand your logic.

I first disable these extension functions in the printf related functions inside Nuttx to ensure that they are not called in the standard printf,

do you mean CONFIG_LIBC_PRINT_EXTENSION?
i don't object against the option if it's meant as a process of deprecation/removal.
i don't think it's a good idea to add a new extension (%pB), though.

I don't selectively read your comments。

ok. then probably i just don't understand your logic.

I first disable these extension functions in the printf related functions inside Nuttx to ensure that they are not called in the standard printf,

do you mean CONFIG_LIBC_PRINT_EXTENSION? i don't object against the option if it's meant as a process of deprecation/removal. i don't think it's a good idea to add a new extension (%pB), though.

My previous logic was:
First, this patch is to deal with the problem of size overflow, and use macros to prevent the size from overflowing.
Later, it became a discussion about %p.
The initial idea was that %p* related uses already existed, %pB might not conform to the definition of printk, and there was no such definition in printf.

@yamt
Currently we support %pS %pV, why not allow add a %pB.
If you think that we should NOT support %pB, then you should remove %pS & %pV.
If you don't remove, then you have NO reason to prevent this PR.

@yamt Currently we support %pS %pV, why not allow add a %pB.

because it breaks more cases.

If you think that we should NOT support %pB, then you should remove %pS & %pV.

i agree they should be removed.

If you don't remove, then you have NO reason to prevent this PR.

i disagree. it breaks more cases.
printf("%pB", p) was not broken with %pS or %pV.

At least, if you don't enable ALLSYMS or DEBUG_UORB, nothing breaks. Both ALLSYMS and DEBUG_UORB is only for debugging, it's fine to lose some very vary compatibility in this case.

At least, if you don't enable ALLSYMS or DEBUG_UORB, nothing breaks. Since both ALLSYMS and DEBUG_UORB is only for debugging, it's acceptable to lose some very vary compatibility in this case. Actually, we ship more 40 million devices which come from BLE only module, WiFi/BLE combo module, watch/band, TWS earbud, smarter speaker..., but I have not hear the incompatible report like this.

i disagree. this should be reverted.

why? if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why?

because it breaks printf.

if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why? they are misfeatures which should be removed too.

why?

because it breaks printf.

LIBC_PRINT_EXTENSION, ALLSYMS and DEBUG_UORB aren't enable by default, how do they break printf?

if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why? they are misfeatures which should be removed too.

So, you want removing ALLSYMS functionality from the code base? @anchao please take a look.

why?

because it breaks printf.

LIBC_PRINT_EXTENSION, ALLSYMS and DEBUG_UORB aren't enable by default, how do they break printf?

if you never enable it, nothing breaks.
however, these options are meant to be enabled in some cases, right?
as i said earlier in this pr, it's unrealistic to audit all printf family usage when enabling the options.

if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why? they are misfeatures which should be removed too.

So, you want removing ALLSYMS functionality from the code base? @anchao please take a look.

at least they should be implemented in a way which doesn't break printf.

Before the perfect way implement, is it more suitable to add the warning message in ALLSYMS and DEBUG_UORB instead removing the related code？

Before the perfect way implement, is it more suitable to add the warning message in ALLSYMS and DEBUG_UORB Kconfig instead removing the related code？

do you mean something like https://github.com/apache/nuttx/pull/14378 ?

@xiaoxiang781216 @Otpvondoiats after this PR nrf52832-dk/timer example crash in timer example. it revert 9de0465a8a fixes crash.
So it's possible that other things are broken too.

at other things are bro

@xiaoxiang781216 @Otpvondoiats after this PR nrf52832-dk/timer example crash in timer example. it revert 9de0465a8a fixes crash. So it's possible that other things are broken too.

@xiaoxiang781216 @Otpvondoiats after this PR nrf52832-dk/timer example crash in timer example. it revert 9de0465a8a fixes crash. So it's possible that other things are broken too.

@xiaoxiang781216 @Otpvondoiats after this PR nrf52832-dk/timer example crash in timer example. it revert 9de0465a8a fixes crash. So it's possible that other things are broken too.

hi, What model is the NRF52832-DK development board you are using?

I see that the problem is different. This PR is not guilty, but after reverting the mentioned commit, the chip resets without a visible assert, making it harder to notice the error.

@Otpvondoiats I see that the problem is different. This PR is not guilty, but after reverting the mentioned commit, the chip resets without a visible assert, making it harder to notice the error.

The culprit is here #13606 :)

I looked at the code of NRF52832-DK, and there is no place to call %p related content. I will run a piece of this board to see if there is any error。

You don't have to check, this PR is not guilty. With this PR for some reason crash is visible, but the reason is different.  https://github.com/apache/nuttx/pull/13606 is the problem. False alarm on my side, sorry for the confusion  :)


nixos/syncthing: turn into RFC42 style settings

Description of changes
alternative to https://github.com/NixOS/nixpkgs/pull/233377
fix https://github.com/NixOS/nixpkgs/issues/232679

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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.05 Release Notes (or backporting 22.11 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

[ ] Fits CONTRIBUTING.md.

Though this fix is going to break the people who expected/use those defaults, isn't it?

I don't think so. Syncthing retains settings between reboots, and those users will just continue have the same settings, but they will be defined imperatively from now on.

How does syncthing handle null values?

How does syncthing handle null values?

it should ignore them because they are invalid. Since I couldn't find anything in the docs I just tested this manually:
I first took the default config and looked at the value options.limitBandwidthInLan: which is false.
I dumped the config, changed the value to null, PUT the new config, was still false. then I changed it to true, PUT it, was true afterwards, after PUTing null again it was still true. So this seems like the perfect behavior for us

We'll revisit this when there's no emergency. Reverted for now.

alright, have added a revert of the revert here so we can continue after branch off

How does syncthing handle null values?

it should ignore them because they are invalid.

That sounds great. To further improve this, we can filter those null values prior to generating the script.

We'll revisit this when there's no emergency. Reverted for now.

I was, and still optimistic we can reach an agreement until the branch off - we are all responsive and engaged. Hence my response is a polite :-1:.
Also, there was a lot more to be said. For instance, I think that my PR might have also fixed the issue for @RaitoBezarius - as it makes the script iterate each attribute in settings individually.

Though I am rather sure the solution would have worked for you.

I am certain too, but I am an advanced NixOS user, I don't care about me :P. I have to care about the others. :)

I think this PR can be marked as ready for review, since the release-23.05 branch off has already been done.

Correct, please write NixOS tests to figure out the right semantics for the fix if you cannot get someone to test your changes :)

In addition to making sure in a nix-repl that lib.converge function works as expected, with raito.nix from my comment at #232679, I added a nixos test that makes sure that no syncthing-init.service service is created when no settings are defined. I also checked manually that if I add a settings.options.relaysEnabled = true; then the test I added fails.

from my side this look ready.

It's not. I don't have time to do a proper review now. Do not merge.

If you want this to go anywhere, please bring this PR down to the bare minimum needed to support arbitrary settings. A couple freeformTypes should do, we can think about reorganising the module and when exactly syncthing-init should be enabled later.
converge (filterAttrsRecursive ... is an abomination and I'm a bit worried that everyone seems fine with it.

thats generally used quite often with freeformTypes, like in home-assistant, keycloak, bookstack. I don't see any upside moving folders and devices out of settings again, since the extraConfig gives the same functionality anyway and causes weird double configuration scenarios. I could rework it anyway but it seems like a bit of redundant work.

thats generally used quite often with freeformTypes, like in home-assistant, keycloak, bookstack.

By "thats" you mean converge (filterAttrsRecursive?

thats generally used quite often with freeformTypes, like in home-assistant, keycloak, bookstack.

By "thats" you mean converge (filterAttrsRecursive?

ah yeah :D , for some reason my quote reply failed.

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/home-automation/home-assistant.nix#L14
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/video/frigate.nix#L21
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-apps/monica.nix#L408
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-apps/snipe-it.nix#L429
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-apps/keycloak.nix#L471
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/security/kanidm.nix#L6
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-apps/bookstack.nix#L394
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/monitoring/parsedmarc.nix#L472
are the ones I could find

@ncfavier do you have a rough estimate when you will come around to review this or https://github.com/NixOS/nixpkgs/pull/234262 ? right now this is in limbo and I'm not aware of any more regressions with this PR

@infinisil may I ask for your opinion? I'm not sure how to best implement RFC 42 here; the proposed solutions leave me deeply unsatisfied and I can't seem to articulate why or suggest alternatives.
Particular points I'm iffy about:

moving devices, folders option trees down under settings (they seem like important options that should be easily accessible)
removing watch, watchDelay, rescanInterval in favour of their API-internal names fsWatcherEnabled, fsWatcherDelayS, rescanIntervalS (ditto, I guess)
the horrible cleanedConfig hack; I've suggested looking at options.services.syncthing.settings.isDefined before to determine whether to enable the syncthing-init service, does that seem like a better idea?

Just to write down my thought process and different tradeoffs I thought about while implementing these changes:

* moving `devices`, `folders` option trees down under `settings` (they seem like important options that should be easily accessible)

since .settings is a freeFormType and describes the API endpoint, having these outside of settings would cause some weird behavior where people could define folders/devices twice, once through services.syncthing.folders and through services.syncthing.settings.folders.
We could strip the folders from settings but that would make it more obscure and we would stray away from the API.
Ideally I want people to dump their current config and just put that into settings to make it declarative.

* removing `watch`, `watchDelay`, `rescanInterval` in favour of their API-internal names `fsWatcherEnabled`, `fsWatcherDelayS`, `rescanIntervalS` (ditto, I guess)

this is similar to the previous issue, but I don't see a quick solution. If we turn folders into a freeForm people could define rescanIntervalS directly and we would need to handle to conflict with our current/previous rescalInterval.
But not sure which one should win in that scenario?
Also the current settings has a default which ideally would need to keep in sync with upstream if the default changes there.
Also there is no way to just ignore the value completely and have it set manually in the webinterface, since it would be override with the default value of the option. The new code would let people have folders declaratively but be able to change folder settings manually.

* the horrible `cleanedConfig` hack; I've suggested looking at `options.services.syncthing.settings.isDefined` before to determine whether to enable the syncthing-init service, does that seem like a better idea?

I looked into isDefined, but if a freeForm has options with default values (it breaks without those default values in my tests) it seems to always be true. Also stripping empty sets and nulls gives us the ability to have documentation for certain options without forcing them to a default value by simply setting them to null. Other alternatives I tried out made the check more complex and gave us less features with more edgecases to handle in the future. Like when people add more option.

Part 2 of RFC 42 encourages adding extra options beside settings when it makes sense. So I agree with @ncfavier that devices, watch, etc. would make sense to keep as options.
@Lassulus it shouldn't be a problem if these extra options are implemented in terms of settings, something like this:
settings.fsWatcherDelayS = cfg.watchDelay;

the horrible cleanedConfig hack; I've suggested looking at options.services.syncthing.settings.isDefined before to determine whether to enable the syncthing-init service, does that seem like a better idea?

I think isDefined is something that should never be used for NixOS modules, because it leads to cases where things can change depending on the priority of options, even though all options are set to the same value, which is very unintuitive.
Most likely this is also the reason upstream why the cleanedConfig hack is necessary here, because upstream config behavior changes depending on whether the default is used or the value is set explicitly, even though the values might be the same. This could be caused by the upstream config not providing any way to set the default.
So I think ideally this should be fixed in upstream so that we don't need the cleanedConfig hack here, but until then I think it's fine to have it. I like it better than having to rely on isDefined.

(isDefined wouldn't work anyway, as @Lassulus points out, so we would have to use something like options.services.syncthing.settings.highestPrio > (mkOptionDefault {}).priority, but I imagine your concerns apply all the same?)

BTW I'd really like to get this merged so that I can get https://github.com/NixOS/nixpkgs/pull/230196 going as well...

I didn't understand the point of configuring settings in terms of their aliases

Me too, but if others will insist, perhaps we can force the user to use (in this example) watchDelay and not fsWatcherDelayS, by triggering a warning or throwing an error if the later is used.
I'll be able to live with the above suggestion, but I still think it's not too bad to ask our users to change some of these settings in order to conform to upstream's terminology - making us and the NixOS modules' users' maintenance burden easier

So what is the status of this?

well I tried to bump some people but basically we are in review hell since @nbp still seems unhappy with the solution? not sure exactly how to proceed. But the current solution still seems like the best we can come up with. having devices and folders outside of settings would be misleading since they end up in settings anyway. and discoverability should be the same since documentation is generated either way?
I would be very happy if we could merge this and fix stuff later if it comes up. but even the last regressions before the channel bump were mainly because syncthing-init ran in weird circumstances where it should not.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-in-distress/3604/62

How about making the type of settings nullOr (submodule ...) and defaulting to null? That way the check is just cfg.settings == null.

Ah we tried that already but the default value of settings gets overriden by the default values of the sub options

since communication with @ncfavier seems kinda stuck (please don't take it as an offence) and there are no other voices against merging this, I will self merge this. We are already like 1/3 of the time to a new release and there seems no forward movement and the closer we come to a release the bigger the fallout we have to fix last minute if something unexpected happens (again?)


Add review/manual resolution of couchdb conflicts.

Right now all couchdb conflicts are solved automatically by the couchdb listener here:
https://github.com/HospitalRun/hospitalrun-dblisteners/blob/master/dblisteners/merge-conflicts.js
While this should produce a hands free resolution process it could be nice to have a screen where admins can see conflicts that were resolved and (optionally) manually resolve those conflicts differently if needed.
Expected behavior:
There should be an admin screen where administrative users can see automatically resolved conflicts and manually override those conflicts if needed.
Actual behavior:
The screen doesn't exist
Steps to reproduce:
NA
Screenshots (if applicable):
NA
OS and Browser:
All

is there any manual about how to use software itself for users and not develooers?


%20 in appDomain.ApplicationBase instead of space

<IP_ADDRESS>
var runtime = clrVersion.CreateRuntime();
var appDomain = runtime.AppDomains.First();
Console.WriteLine("Directory:      {0}", appDomain.ApplicationBase);
Directory:      E:\svn\randomname%204.0\bin\
Correct name: E:\svn\randomname 4.0\bin\

" The internal representation of this value actually has "%20" in it and we want to accurately report what's there."
Wow, that's crazy since %20 is actually a valid directory name. If I have two directories "randomname%204.0" and "randomname 4.0" it is impossible to tell them apart. I wonder if this can be used for malice somehow:-)


Travis CI for other lyraproj repos (other than lyraproj/lyra which already has it)

Is your feature request related to a problem? Please describe.
Run CI (test/lint) on various lyraproj projects not yet covered.
Describe the solution you'd like
Tests and linting to match lyraproj/lyra
Describe alternatives you've considered
N/A
Additional context
Check how travis is rate limited and check no impact there.

To add travis to a repo

go to , sign in and navigate to settings in top right
Should take you to https://travis-ci.org/account/repositories
Select lyraproj organization
(assume must be owner of https://github.com/lyraproj and have sync-ed in travis via "sync organization)
Should take you to https://travis-ci.org/organizations/lyraproj/repositories
Toggle repos on and off as per image below
Add .travis.yml in a PR

Where do the results end up? Maybe do those fancy badge things on each repo?

https://www.traviscistatus.com/

We are seeing an increase in the build backlog and we are looking into it. Thank you for your patience.

Where do the results end up? Maybe do those fancy badge things on each repo?

Also on the PR page itself https://github.com/lyraproj/pcore/pull/4

oh, right, of course 🤦♂

This work is complete.


Roll engine 3c51a7bfff77..e695a516f148 (9 commits)

https://github.com/flutter/engine/compare/3c51a7bfff77...e695a516f148
git log 3c51a7bfff776e9e3011384f4ff09c13a697c6b6..e695a516f148cef9c7850a6e00151f00bfadf0d4 --no-merges --oneline
e695a516f Add FLEDartProject for macOS embedding (flutter/engine#9672)
44f2f07ff Roll src/third_party/skia e192c4ce5a33..829b6a0ff49f (1 commits) (flutter/engine#9705)
d5f15d1cd Roll src/third_party/skia de6758683abd..e192c4ce5a33 (2 commits) (flutter/engine#9703)
e46532986 Roll src/third_party/skia 2f62edf1ac5d..de6758683abd (1 commits) (flutter/engine#9700)
05966cd14 Roll src/third_party/skia 1d105080c423..2f62edf1ac5d (1 commits) (flutter/engine#9699)
b132baa44 Ensure that platform messages without response handles can be dispatched. (flutter/engine#9698)
50d622857 fix Picture.toImage return type check and api conform test. (flutter/engine#9685)
001bb541c Roll src/third_party/skia 8063f6cca025..1d105080c423 (3 commits) (flutter/engine#9692)
db4d6836a Roll src/third_party/skia 857c9f955edb..8063f6cca025 (3 commits) (flutter/engine#9679)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (jsimmons@google.com), and stop
the roller if necessary.

Auto-roller completed checks. About to merge.


MRTK Shaders should support SRP Batcher

Overview
Draft of work to update MRTK shaders to support SRP batcher in new scriptable rendering pipeline in Unity.
Changes

Fixes: #7434

Verification

As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch

Great to see there has already been work on this item. Is there an ETA on this change to be merged?

So the shaders no longer are all marked as SRP batch compatible, however when trying to use the shader to make a material, the shader ends up looking like the "material not working" pink color.
Online tells me to run through this step
https://answers.unity.com/questions/1519382/textures-and-materials-turn-pink-after-installing.html
however after doing so I get these kinds of errors:

@rwetzold  you had filed the original issue, how were you able to get the MRTK_Standard_shader materials to work with the Universal Render Pipeline?

I just setup an empty URP project in 2020.1 and indeed can verify the 2.5 shader version is pink. Something got broken since 2.3. To verify I copied the 2.3 version of the shader into the project and voila, it worked again (just the batching is broken as per this bug here).
Side-note: the 2.5 version has a misspelling in the rim shader causing Unity to show 2 MRTK folders with slightly different spelling in the shader list.

@RogPodge in MRTK we have a "unique" upgrade path for the URP which you can see how to invoke here: https://microsoft.github.io/MixedRealityToolkit-Unity/Documentation/README_MRTKStandardShader.html#lightweight-scriptable-render-pipeline-support
It's probably time we change the name from lightweight to universal after Unity's re-branding. :D Also, it would be nice if we could hook into Unity's existing upgrade menu item, but when I wrote it (many months ago) there was no hook. Maybe there is now?

I just setup an empty URP project in 2020.1 and indeed can verify the 2.5 shader version is pink. Something got broken since 2.3. To verify I copied the 2.3 version of the shader into the project and voila, it worked again (just the batching is broken as per this bug here).
Side-note: the 2.5 version has a misspelling in the rim shader causing Unity to show 2 MRTK folders with slightly different spelling in the shader list.

What is the rim shader name? I can relocalize it in a future PR/track this issue

/azp run

/azp run

The constant buffer changes look perfect! Do you have any stats on how the batch count was effected by this change?
You should be able to toggle on/off the batcher in the URP config asset. Then you can inspect the number of batches being submitted in the stats window under "Batches."

I see in the Hand Interaction Examples scene we save 62 batches!

/azp run

The constant buffer changes look perfect! Do you have any stats on how the batch count was effected by this change?
You should be able to toggle on/off the batcher in the URP config asset. Then you can inspect the number of batches being submitted in the stats window under "Batches."

I see in the Hand Interaction Examples scene we save 62 batches!

Going to close this PR for now and we can continue the conversation from here: https://github.com/microsoft/MixedRealityToolkit-Unity/issues/8830


doc outdated in Type Inference -> Contextual Type -> example

https://www.typescriptlang.org/docs/handbook/type-inference.html
mouseEvent has property button now
window.onmousedown = function(mouseEvent) {
    console.log(mouseEvent.button);  //<- Error
};

I'm on it


First day with temperature threshold reached does not benefits from RL improvements

The generic first_day_temperature_reached  does not use rl.resample_and_rl, which make the potential improvments of inverting the operation order inaccessible.
https://github.com/Ouranosinc/xclim/blob/edf1e13b7d47e4ead94506cdbb3bce1f977376f9/xclim/indices/generic.py#L947-L953

Proposition doesn't make sense, sadly. Closing.