Refactor package list in preconf role

At this moment list of packages that this role installs looks like this:
    - bc
    - haveged
    - rsync
    - iotop
    - dstat
    - sysstat
    - htop
    - lbzip2
    - pigz
    - unzip
    - zip
    - mtr
    - tcpdump
    - openssh-client
    - sudo
    - mc
    - net-tools
    - screen
    - git
    - cloud-utils
    - build-essential
    - nload

They fall into different categories but it is impossible to tell what is the exact purpose of each package.
Sysadmin tools mtr and tcpdump are typical examples. Operator uses these packages to troubleshoot issues on the node. If drop these packages node is still operational.
POA Components dependencies If drop these packages some of poa components will stop working. When poa component stops dependency on this packet it should be removed from the system.
Ansible modules dependencies. Ansible modules depend on these packages to do their tasks. If the module is not needed then this package should not be installed.
The proposal:

Move ansible modules dependencies to the role level where they are used.
Move POA Components dependencies to the role that installs these components.
Refactor Sysadmin tools into a separate role that user may choose to install optionally.
Install no packages in the preconf role

Looks like Sysadmin tools are:

rsync
- iotop
- dstat
- htop
- sysstat
- tcpdump
- net-tools
- mc
- cloud-utils
- mtr
- nload
- screen
But I'm not sure about network components dependencies
- bc
- haveged
looks like smth related.
And probably
- lbzip2
- pigz
- unzip
- zip
are also necessary for some POA components.
@phahulin Probably you can clarify? If no, I'll investigate in our sandbox.

@phahulin  I see. And maybe you can provide the info, which exact packages use haveged? Or should we install it everywhere?
If so, looks like the expected result will be to have haveged, git, and build-essentials at preconf role, to avoid writing the same code many times. And all other packages in debug-tools optional role, which is used by default.

@Ykisialiou haveged is started as a service by itself when it's installed. It improves random number generator. Other packages don't use it. So it just needs to be installed

Closing because of #127


removed exec's -l parameter as it influence on 0 argument of executed…

solves #174

any notion when this fix will be merged? :)

@dmark04 i've just merged this pr; sorry I didn't know anyone was waiting for this.

Thanks. No need to apologize. There was no rush.


Multiple csv columns with escaped quotes in ydb import file csv command are parsed incorrectly

If a csv line has multiple columns with escaped quotes (double double quotes), each consecutive column overrides previous due to library/cpp/string_utils/csv CsvSplitter behaviour

Most likely same issue occured in https://github.com/ydb-platform/ydb/issues/9813


Windows: Fix identical file tests to compare results as text

For these identical file tests, even the in and out filenames are the same, output file format would change to be DOS format on Windows and that failed the tests.
CLA: trivial

So why don't the tests fail at the moment?

Maybe git been configured to modify line endings?

OK, it is the git config core.autocrlf which I have it false to preserve unix format, even on Windows.
However, wouldn't it be better that the tests are independent of how developers config their git?


Get the pipeline stage result

get the “/wfapi/describe"" content and “/execution/node/" + nodeId + "/wfapi/log“

@huangjiao511 Did you see that there is a merge conflict.  This looks like functionality I could use.


[EXE] Predicting house prices

Learning Goals
PCA, Linear Regression, Lasso Regression, Ridge Regression, Elastic Net and Gradient Boosting Technique
Exercise Statement
Predicting house pricing by using advanced regression techniques.
Using PCA for feature selection.
Prerequisites
Know the basics of each concept stated in learning goals.
Data source/summary:
Kaggle.

Hi @Damanpreet thanks ! This seems cool. Since we already had regression projects on housing prices, it'd be cool to focus on PCA and gradient boosting technique.
Another good thing is to discuss in depths regularization, if that's something you want to do.
Thanks !

@gimseng Thanks for your suggestion, will also try that out!


App crashes as of v5.5.2

Hi Luke,
There was a breaking change in upgrading dayjs in Inkdrop.
It no longer exports default, so the app crashes on loading as follows:
TypeError: (0 , _dayjs.default)(...).fromNow is not a function
    at ThumbnailNoteListItemView (ThumbnailNoteListItemView.js:73:33)

To avoid that, you have to use require()
Hope that helps

Wait, it doesn't happen again when relaunching the app - strange🤔
I've got a bug report from a user, so you should be able to reproduce it.

Thank you for your report.
I didn't get that crash in my environment, but I'll release a patch when I have time.


Explicit/implicit .where — does Rubocop HQ have an opinion?

Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
Our team was discussing a stylistic preference about how to call #where—in, say, the Post model, should it be where or Post.where?
Is there a cop (or would Rubocop HQ consider adding one) to enforce one style over the other?
Describe alternatives you've considered
N/A
Additional context
FWIW, it appears that in some of the large-scale open source Rails applications I've looked through, there tends to be some inconsistency, with a strong tendency toward implicit wheres:

GitLab CE has 294 implicit / 5 explicit
Discourse has 98 implicit / 70 explicit
RubyGems.org has 26 implicit / 3 explicit

While the core team may individually have opinions on style, the RuboCop core team doesn't. We are just concerned with building the linter. Ruby is a long standing language, and people are already quite cemented in their opinions of style. Trying to have an official stance inevitably leads to a lot of bike shedding, and people opening issues to forcefully promote their own preferred style, which is draining, and detracts from the work. (The Ruby Style Guide repo is a great place for people to discuss though.)

Super cool! I'll take a peek at what it takes to build a cop one of these weekends, just to see if I can contribute here myself. Thanks!


How can I add firebase into it and store every element I selected or input in.

How can I add firebase into it and store every element I selected or input in.

well the content of the each step are your own components, so you are free to do it anyway you want...


New release

There's a been a few updates and successful pull requests. Can we get a new version released?

Released 0.4.5 today. Contains fixes from July 26th to August 12th.


Delete request returns an exception

[x ] Bug
[ ] New Feature

What version of Serilog.Sinks.Elasticsearch is affected?  Please list the related NuGet package.
8.0.1
What is the target framework and operating system? See target frameworks & net standard matrix.
-[x] netCore 3.1

[ ] netCore 2.0
[ ] netCore 1.0
[ ] 4.7
[ ] 4.6.x
[ ] 4.5.x

Please describe the current behavior?
I'm trying to do a simple Delete, but using the already specified version of this client with Elasticsearch 7.11.0, I get a message in the OriginalException field telling me the request I'm trying to do does not support having a body.
Here's the message:
[Elasticsearch.Net.ElasticsearchClientException: Request failed to execute. Call: Status code 400 from: DELETE /myindex/_doc/myDocKey ServerError: Type: illegal_argument_exception Reason: "request [DELETE /myindex/_doc/myDocKey] does not support having a body"
I figured it could be some type of version-related incompatibility
Please describe the expected behavior?
The delete request returns a successful response
If the current behavior is a bug, please provide the steps to reproduce the issue and if possible a minimal demo of the problem

A delete verb with a body is not common and in some cases is rejected, but I m wondering where in the sink you try to do a delete operation?

Thank you very much for your response!
I'm sorry. I thought the problem I was having was related to the sinks but it turned out it certainly was a versioning problem but with the version of NEST package I was using.
Sorry for any inconvenience!


Menu bug

Laravel Version: 5.4.26
Voyager Version: 0.11.12
PHP Version: 7.1
Database Driver & Version:

Description:
Can anyone help me with this menu display bug? Json_decode expect sting but not an object after creating a new menu with two translations and dynamic route.
Steps To Reproduce:
I created a new Menu with 2 translations. I added one route item and now i get this error
json_decode() expects parameter 1 to be string, object given
/vendor/tcg/voyager/resources/views/menu/admin.blade.php

@marktopper @fletch3555
This is issue what i wrote month ago.

Maybe this could be a solution: https://github.com/the-control-group/voyager/pull/1101#issuecomment-293860578

@AdrianKuriata, maybe you can test if the comment from above solve the issue? If that is the case, I will reopen your PR so you can make the change.

I can't try it because i delete it from database, created a new one with static url and now i have this problem
#1343

@marktopper if it is not a problem i will do this on the weekend, but from my PR i will try your solution and eventually i repair it and will create a new PR.

@AdrianKuriata, sure, no problem 😄

@marktopper i did this
`protected function prepareParameters($parameters)
{
if (is_string($parameters)) {
$parameters = json_decode($parameters, true);
} else if (!is_array($parameters)) {
$parameters = json_decode(json_encode($parameters), true);
}
    switch (array_get($parameters, 'type')) {
        case 'route':
            $parameters['url'] = null;
            break;
        default:
            $parameters['route'] = null;
            $parameters['parameters'] = '';
            break;
    }

    if (isset($parameters['type'])) {
        unset($parameters['type']);
    }

    return $parameters;
}`

and now when i click save i get this error
json_decode() expects parameter 1 to be string, object given (View: /vendor/tcg/voyager/resources/views/menu/admin.blade.php) (View: /vendor/tcg/voyager/resources/views/menu/admin.blade.php)
and still i get this error too #1343

Yea, i will fix it today or tommorow, you must wait for PR.

ok thank you very much

Fixed by #1355


XDG_CONFIG_HOME not used / potential overflow

I have a patch for this but as I'm in work I can't build and test it - https://gist.github.com/steven-jackson/b388215f239af9f9bfe0
sway/config.c Lines 43 and 96
As you can see the home variable is copied to temp, but xdg_config_home contains the path that should be copied. If home is larger than xdg_config_home then an overflow can occur.

Thanks! I fixed that bug, but I didn't feel that it was necessary to merge your entire patch for several reasons.

Okay...

Well, to elaborate:

Several style errors in your code
Not convinced it's necessary to add a whole join function
This code is slated to be rewritten later anyway

So, not worth the effort.

It matches the style perfectly - there is already inconsistent attachment of pointers to types / identifiers and inconsistent use of space before an opening bracket.
You can check for a NULL return from malloc in a single place instead of fixing it in each place, which is what I should have done.
Irrelevant

Apparently it wasn't worth my effort either.


  This is the expected behavior of the build system.

OPS Build status updates of commit ebad632:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

dynamics-gp/payroll/CAN18YETax.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Update site-recovery-components.md

Minor typos

Hi @amoedo, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

Thanks, @amoedo


[stable/fluentd] Fix pvc creation in fluentd chart

What this PR does / why we need it:
Fix broken fluentd chart when var persistence.enabled: true
Which issue this PR fixes
Double pvc creation and deployment fails.
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

@jmferrer
Could you sign DCO and bump chart version to latest please? Thank you.

Hi @zanhsieh , I close this merge request and open other which I expect to be correct:
https://github.com/helm/charts/pull/18340
Please, let me know if I do something wrong.


Simplify container api

Changed

Updated ContainerApiServiceImplementation.#containerService to be protected _containerService.
Updated ContainerApi to inherit ContainerApiService.

Codecov Report

Merging #9 (4d0d4e8) into master (c295a93) will decrease coverage by 2.79%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master       #9      +/-   ##
==========================================
- Coverage   95.97%   93.18%   -2.80%
==========================================
  Files          32        6      -26
  Lines         596       88     -508
  Branches       91       12      -79
==========================================
- Hits          572       82     -490
+ Misses         22        6      -16
+ Partials        2        0       -2

Flag
Coverage Δ

cuaktask
93.18% <ø> (ø)

iocuak
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...kages/iocuak/container/modules/api/ContainerApi.ts

.../services/api/ContainerApiServiceImplementation.ts

packages/iocuak/task/models/domain/TaskScope.ts

...cuaktask/ContainerInstanceServiceImplementation.ts

...ckages/iocuak/metadata/utils/getReflectMetadata.ts

packages/iocuak/metadata/decorators/inject.ts

packages/iocuak/metadata/decorators/injectable.ts

.../iocuak/task/models/cuaktask/CreateInstanceTask.ts

...ges/iocuak/metadata/utils/updateReflectMetadata.ts

...s/domain/ContainerMetadataServiceImplementation.ts

... and 16 more

Continue to review full report at Codecov.

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


PyPy Support?

Does CuPy support PyPy? Are there any changes users need to make to ensure a build works with PyPy? If this isn't supported, is there a sense of how much work would be required here?

ref: https://github.com/conda-forge/cupy-feedstock/issues/43#issuecomment-603032749
import cupy is OK, but there's a CUDA_ERROR_INVALID_IMAGE driver error when trying to run CuPy with PyPy.

I think this issue can be closed. I tested the backport PR #3227 with v7.3.0 and it worked (importable, runnable, and passed a few randomly picked tests).
I did see the test TestCumprod.test_cumprod_huge_array failed, though. I got OutOfMemoryError for this. But we should open a separate issue to follow up. Most likely it involves how PyPy does garbage collection, which I assume must be quite different from CPython's.

Yeah to summarize it sounds like CuPy supports PyPy. We may still need to iron out some issues though that are TBD. Does that sound right?

Yes! 🙂


Attribute error.I am using MAC with python 3.6 and tensorflow installed

Feb 13 23:49 summarization.py[line:195] INFO Creating 1 layers of 400 units.
Traceback (most recent call last):
File "src/summarization.py", line 241, in
tf.app.run()
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tensorflow/python/platform/app.py", line 124, in run
_sys.exit(main(argv))
File "src/summarization.py", line 229, in main
decode()
File "src/summarization.py", line 196, in decode
model = create_model(sess, True)
File "src/summarization.py", line 75, in create_model
dtype=dtype)
File "/Users/twister_mn/headlinesg/tfsum/src/bigru_model.py", line 87, in init
decoder_cell = tf.contrib.seq2seq.DynamicAttentionWrapper(
AttributeError: module 'tensorflow.contrib.seq2seq' has no attribute 'DynamicAttentionWrapper'

How were you able to solve this problem.
I am getting the same issue. Please help


Amend rule 217t

Closes #763

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.28%. Comparing base (1a6481e) to head (24f40f8).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #766   +/-   ##
=======================================
  Coverage   95.28%   95.28%
=======================================
  Files         314      314
  Lines        7742     7742
=======================================
  Hits         7377     7377
  Misses        365      365

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Crash when leaving screen without entering any input [Reproducible on the Stripe demo]

Describe the bug
The app will crash when you leave the screen with <CardField /> and the user did not input anything.
To Reproduce
Reproducible on the demo snack
Go to a screen with <CardField />
Try to leave the screen without entering anything in.
Here is a video of the error on the demo snack
Expected behavior
Should be able to leave the screen even if nothing is entered
Screenshots
Here is a video of the error on the demo snack
iPhone SE:

OS Version: 13.4.1
Model: iPhone SE
Expo SDK: 42
Expo type: Managed
Stripe Version: "@stripe/stripe-react-native": "^0.1.4",

Additional context
I noticed, that if the user enters any input, they can go back with out any issues.
Since this was marked as usable for production, we pushed this build to production already. Is there a quick fix that we can deploy?

I'm not able to reproduce this. @brentvatne @cruzach any ideas?

I am also not able to reproduce. Would be helpful to know if you also get this behavior in your standalone app- that would indicate an issue outside of Expo Go (so I'm assuming in the stripe-react-native code). Best way to find out where is to investigate the logs/stack trace of the crash

I believe this is the same issue as https://github.com/stripe/stripe-react-native/issues/391

I wanted to comment and saw that i am also seeing this issue. Expo SDK 42 i.e "expo": "~42.0.1", installs  "@stripe/stripe-react-native": "^0.1.4" by default. Using the <CardField /> component does cause iOS to crash.

I copied this code from this Stripe Example
When i run expo start -c and load it on my ios devices (and simulator!) this is the screen i get when i submit the payment. I am using expo SDK 42.

@Legym this is related to this https://github.com/stripe/stripe-react-native/issues/440, this is fixed already in the latest library version, unfortunately you need to wait for the next release of expo to get this fixed there. However this is related to the react-native version which doesn't support certain methods which library uses yet, so you are able to fix it on your own by upgrading RN to 0.63.x or higher

This fix won't land in Expo Go until our next release (SDK 43), but you can get it in your standalone app built with eas build since that picks up whatever version of react-native and @stripe/stripe-react-native you have set in package.json

this is fixed and released now (including through Expo)


Added default option for PDB.

Setting LinkerPdbFilePath to null or an empty string will make Visual Studio use the default.
Setting CompilerPdbFilePath to null or an empty string will make Visual Studio use the default.

That will create a conflicting behavior with FastBuild, as in that case, you won't generate a pdb at all.


[INTERNAL] package.json: Allow npm >= v8

There is no actual need to increase the minimum npm version. Lockfile v3 is already supported

coverage: 94.709% (+0.08%) from 94.629%
when pulling 5cf4dad83617ae587faa734fdbe9d1b0f202a047 on expect-npm-8
into 8f0990f659127271386a6952b8c1936277b5e69c on main.


Layout with flexible cols

Component change
Allows sidebar col to be customizable, calculating main col accordingly
col 6

col 3

Other

createsSTORYBOOK environment variable and fetch_or_fallback will not fail if that env var is true
separates centered and normal layouts so we can use them depending on how we want to render sotrybook for each component

@jonrohan I don't think the changes will make it harder, it should actually help if we intend on allowing custom sizes for each layout :)


cloneNode issue for hoisted vnode

Version
3.0.2
Reproduction link
https://codesandbox.io/s/adoring-sinoussi-bsqni
Steps to reproduce

first mount, Chart display correctly
click toggle button twice to mount Chart again,  it just display blank

What is expected?
I hope the chart could display correctly after remount
What is actually happening?
In production mode, the chart just display blank after remount

I found something on MDN.
cloneNode on mdn

It does not copy event listeners added using addEventListener() or those assigned to element properties (e.g., node.onclick = someFunction). Additionally, for a  <canvas> element, the painted image is not copied.

call of cloneNode in vue source code
I want to know why the hostCloneNode must be called and in what scenario. Could vue just reuse the exact same hostNode without cloning it because it's "static"😂?

You have to dispose the chart when the component is destroyed
onUnmounted(() => {
      myChart.dispose();
    });


Remove raiden-libs dependency

raiden-libs are being deprecated. We need to remove the dependency on the package.
As @palango documented, we need to remove:
raiden_contracts/deploy/__main__.py
32:from raiden_libs.private_contract import PrivateContract
33:from raiden_libs.utils import get_private_key, private_key_to_address

raiden_contracts/tests/conftest.py
1:from raiden_libs.test.fixtures.web3 import *  # flake8: noqa
2:from raiden_libs.test.fixtures.address import *  # flake8: noqa

raiden_contracts/tests/deprecation_switch_testnet.py
5:from raiden_libs.private_contract import PrivateContract

raiden_contracts/tests/property/test_tokennetwork.py
22:from raiden_libs.test.fixtures.web3 import ethereum_tester
23:from raiden_libs.utils import private_key_to_address

raiden_contracts/tests/utils/contracts.py
4:from raiden_libs.test.fixtures.web3 import (
8:from raiden_libs.utils import private_key_to_address

raiden_contracts/tests/fixtures/utils.py
4:from raiden_libs.utils import private_key_to_address

Replacing raiden-libs dependencies is done in https://github.com/raiden-network/raiden-contracts/pull/379.
Opened two issues for the rest of the work needed to be done:
https://github.com/raiden-network/raiden-contracts/issues/380 (Replace raiden-libs PrivateContract)
https://github.com/raiden-network/raiden-contracts/issues/381 (Replace raiden-libs get_private_key)
Once https://github.com/raiden-network/raiden-contracts/pull/379 is merged, we can close this issue.


Displaying Math Equations from ChatGPT responses.

Hello, I got a response from ChatGPT and tried to display it with SwiftMath but it didn't work:
Here is the response:
To solve the equation \(3x + 5 = 4\), follow these steps:
what format is this string of text:
1. Subtract 5 from both sides of the equation to isolate the term with \(x\):
   \[
   3x + 5 - 5 = 4 - 5
   \]
   Simplifying this, we get:
   \[
   3x = -1
   \]
2. Divide both sides by 3 to solve for \(x\):
   \[
   x = \frac{-1}{3}
   \]
So, the solution to the equation \(3x + 5 = 4\) is:
\[
x = -\frac{1}{3}
\]

When I tried with another package I get the error: Undefined control sequence \(
I don't know what I need to do to be able to display these type of response.

This is LaTeX output. SwiftMath only supports a subset of LaTeX, namely equations.

@mgriebling Thank you for your response. Do you have any recommendations on how to display this type of LaText output in SwiftUI?

Maybe look at embedding MathJax within a web browser view.


Add a bitHound badge.

I saw you had an issue open for adding the bitHound badge. I thought I'd lend a helping hand :smile_cat:

[x] Add the bitHound badge to README.md

Closes #28

Sweet, thanks @carlosperez!


Timeout is described as time with units but being parsed as int

In the documentation:
https://steeltoe.io/docs/steeltoe-configuration/#2-2-2-configure-settings
timeout is described as having default value of "6s", however the client code seems to be expecting an integer, and defaults to "6000" if none is found.
So, for example having these settings in appsettings.json:
{
  "spring": {
    "application": {
      "name": "sample-application"
    },
    "cloud": {
      "config": {
        "uri": "http://config-server-url.io:8080"
        "timeout": "15s"
      }
    }
  }
}

will still result in sending timeout of six seconds "6000"

That sure looks like an error in the documentation. The property in the Configuration client is most certainly an integer, and there doesn't appear to be anything that would handle that conversion. Docs are updated in source, we'll get that change to the live docs site soon.


[FLINK-7724][REST][Tests][Metrics] add extra metrics to MetricStoreTest.setupStore

What is the purpose of the change
This is a pre-requisite for FLINK-7694
I'm porting JobMetricsHandler to new REST endpoint. Part of the migration is to make sure the json generated before and after stay the same for UI to consume, and JobMetricsHandler is using MetricStoreTest.setupStore() to get a mocked MetricStore.
Here comes the problem. Currently, MetricStoreTest.setupStore() mocks all jobs with only one metric. We need to have at least one or two jobs with multiple metrics to make the mocked MetricStore can cover most use cases, and ensure the Json blob generated in JobMetricsHandler stay the same before and after migration.
Brief change log

make two jobs in MetricStoreTest.setupStore() contain multiple metrics

Verifying this change
This change is already covered by existing tests
Does this pull request potentially affect one of the following parts:
none
Documentation
none

cc @tillrohrmann  @zentol

merging.


add block to best chain

Current dependencies on/for this PR:

feature/proof-of-stake

PR #649

PR #712

PR #705

PR #706

PR #707

PR #708

PR #713

PR #714   👈

This comment was auto-generated by Graphite.


Enhance detection of MUSL-based Linux systems (xgboost4j)

Context
With the release 1.6 of xgboost, a feature was added that would automatically detect under Linux, whether it is a regular or a MUSL-based system. Depending on this, the proper Native shared library would be loaded (MUSL-based systems cannot load shared libraries using glibc).
The check whether a Linux system is MUSL-based is done by inspecting memory-mapped files in /proc/self/map_files. This is the same logic as the sqllite-jdbc project is doing here.
Problem
While this typically works well, there are cases, where this directory is not accessible. There are at least two cases:

since /proc/self/map_files was added in Linux kernel 3.3, for older kernels this directory simply does not exist
some versions of the kernel do not allow access to this directory for non-root users

This problem has also been discussed on the sqlite-jdbc forums. See here for a good summary of the problem.
The current implementation in xgboost assumes, that if this directory cannot be read for some reason, the Linux system is not MUSL-based.
Unfortunately, this assumption is not always correct.
Proposal
We need another way to determine whether a Linux system is MUSL-based or not. It seems, there is no simple auto-detection, that works 100% for all cases and environments. Therefore, I propose that the user can give a hint to xgboost, whether the Linux system is MUSL-based or not.
(1)
In the class NativeLibraryLoader we check for the presence of a custom environment variable like IS_MUSL. If this env variable is present and its value is truthy (true or 1), xgboost assumes the system is MUSL-based, no matter whether memory-mapped files in /proc/self/map_files can be read or not.
(2)
If this custom environment variable is not present, then detection falls back to the current solution.
This could be simplified by defining that you always have to configure the IS_MUSL environment variable, if you're running on a MUSL-based system. But since it seems to work most of the time, it still seems convenient for most users to keep the current detection mechanism.
How does this work for the end user?

If you're running xgboost on a regular (glibc-based) Linux system, there's nothing to consider.
If you're running xgboost on a MUSL-based Linux system and auto-detection detects this correctly, there's nothing to consider.
If you're running xgboost on a MUSL-based Linux system and auto-detection fails to detect this, you'll get an ugly failure when xgboost is trying to load the shared library. The error message should then include a clue, that you may want to use the IS_MUSL environment variable to override this.

Please let me know what you think! I can create a PR with the suggested change.

Thank you for the proposal.  @Craigacp would you like to join the discussion when you are available?

I think my preference would be to remove the MUSL section from NativeLibraryLoader and supply a single JVM system property override for users which allows them to supply the path to the XGBoost native library on startup, rather than have a two phase approach where the user can override MUSL detection but has a leaky fallback. That's what we do in ONNX Runtime (https://github.com/microsoft/onnxruntime/blob/master/java/src/main/java/ai/onnxruntime/OnnxRuntime.java#L273) to support other use cases as well as this one (e.g. frozen containers which don't have a writable /tmp), and it will allow the library loading logic to be simpler. Users who choose to use a MUSL libc are already compiling things from source so they should be capable of jumping through an additional hoop.
That said, I'll ask around with some Java people to see if there is a way to reliably detect it from within the JVM (e.g. I'm not sure how stable the output of ldd $JAVA_HOME/bin/java would be, but grepping that might work) as if we can remove the instability that way then that's fine.

The consensus opinion from the Java people I talked to is that there are only bad ways to detect if you're running on top of musl directly from within the JVM and that those shouldn't be in production code.

Thank you for the comments. Is there a way to fail gracefully?

@Craigacp
Thanks for your input! I can see that getting rid of the MUSL auto detection makes sense, as it doesn't work in all cases anyway and simplifies the code.
Concerning your suggestion that the user could specify the path of the shared library to load via an system property:

On the positive side, this could be used for other scenarios, we're not yet aware of, as you've mentioned. We would simply use this value, if it is present, no matter what OS or architecture it runs on.
On the negative side, this might be suboptimal with respect to security. I cannot come up with a specific scenario, but surely, less things can go wrong, if you only provide a way via a boolean value (like IS_MUSL) as opposed to a full path.

WDYT?
@trivialfis
I'm not sure what you mean with "Is there a way to fail gracefully?" Which scenario do you mean?


Respond with UNIMPLEMENTED when a requested method is not found

My favorite part is the added test coverage.

Repushed and back to you; thanks for the comments.

Looks fine to me; waiting on Jenkins.


[Executor] Enhance CommittedChunk to include epoch change LI

[Please consider just the last commit in this PR: the other two commits belong to https://github.com/libra/libra/pull/1930]
Summary:
Added an optional ValidatorChangeEventWithProof field for an epoch change LedgerInfo.
This field carries a LedgerInfo corresponding to the end of the epoch, even if the verified target LedgerInfo is somewhere in the future (as it's the case with the waypoints).
In addition, minor cleanup of the existing code to use the ProcessedVMOutput wrapper functions instead of lower-level checks.
Note that the new optional field is not used yet, so this change is a noop at this point.
Testing:
The existing functionality is tested with the existing unit tests.
The new functionality (epoch change LedgerInfo) is not tested yet: didn't find a simple way to generate a test reconfiguration transaction.
Issues: ref #1384

:umbrella: The latest upstream changes (presumably ff097ba9f01989216311745e8e371b213cba15e5) made this pull request unmergeable. Please resolve the merge conflicts.

Lol, the stateless executor PR https://github.com/libra/libra/pull/1733 kinda changed the whole thing, closing this one, will open another PR


Add ArgParse.jl to pkg dependencies

ArgParse now needs to be manually installed to satisfy runtime dependencies of train.jl

Now included in REQUIRE, ac767c0abcb7f48824d1248ddace58624adaca5f


Feature Request: Mermaid Diagram Support

Obsidian supports mermaid graphs.
I think it may not be too difficult to add to support them in the web?
<script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/8.0.0-rc.8/mermaid.min.js"></script>
<script>mermaid.initialize({startOnLoad:true});</script>

Already, the blog creates  tags with class "mermaid-code".
Mermaid.JS looks for  tags with class "mermaid"  - but I think it can be configured in the init function
mermaid.init(undefined, ".mermaid-code");

I don't know if init and initalize are different, but i guess the full code could look something like thi:
<script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/8.0.0-rc.8/mermaid.min.js"></script>
<script>mermaid.initialize({startOnLoad:true},  ".mermaid-code");</script>

Related Links:

https://www.cloudhadoop.com/2018/08/mermaidjs-tutorial-javascript-diagram.html
https://mermaid-js.github.io/mermaid/#/usage

Btw, there may be a bug with mixing code sections and admonition tags - I am investigating

Normally, mermaid are supported by jekyll spaceship

Oh! Thank you, I will investigate more

After some test with the script, yes, I found the problem :
   for i in range(0, len(file_data)):
        if re.search("[`?!]{3}( ?)ad-(.*)", file_data[i]):
            start = i
            start_list.append(start)
        elif re.match("```", file_data[i]) or re.match("--- admonition", file_data[i]):
            end = i
            end_list.append(end)

It seems to "create couple" with the last brackets of the mermaid

I think we may need to replace
\`\`\`mermaid
with
\`\`\`mermaid!

Yeap, it's also done in my side, but I block on the "couple".
With my test, I have a "start" with one value, and end with two value. So the zip create a list with the 2 first.
Something like :
start = [7]
end = [5, 10]
zip resultat = [7,5]
If you have an idea ?

Okay, I think i found a way. I need to do some test before push

Great :)

or not :<
Pretty difficult to found a way around this, tbh

Have you pushed your branch? Maybe I can take a look

I pushed the dev branch !

Okay, so I work a lot, but I think i found a solution.
It's totally cursed, but it's work


Request for Reference feature of CodeLense

Hello!
I had a proposal to add Сodelens feature - Reference, which would be much more suitable to track the code (especially if the script has a lot of functionality), and also easily navigate which function is being used, and what functionality isn't used so it can be stripped, and also see dependencies in variables, structure and so on.

I'm fairly certain that this will need a new parser (I've started playing around with 4NTLR, but never had the time to finish it). In any case, if you want to try to add the functionality, make a pull request.
Regards.


feat: bb uses goblin

Please provide a paragraph or two giving a summary of the change, including relevant motivation and context.
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

[ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
[ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
[ ] Every change is related to the PR description.
[ ] I have linked this pull request to relevant issues (if any exist).

Benchmark results
Metrics with a significant change:

node_database_size_in_bytes (10): 5,516,564 (+41%)
note_history_trial_decrypting_time_in_ms (10): 225 (-34%)
note_trial_decrypting_time_in_ms (32): 66.4 (+96%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit fd6eefe3 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,444
179,588
716,132

l1_rollup_calldata_gas
222,996
868,292
3,449,504

l1_rollup_execution_gas
842,083
3,595,400
22,204,873

l2_block_processing_time_in_ms
2,347 (+7%)
8,611 (+2%)
35,208 (+1%)

note_successful_decrypting_time_in_ms
318 (-1%)
940 (+4%)
3,412 (+2%)

note_trial_decrypting_time_in_ms
26.4 (-12%)
:warning: 66.4 (+96%)
200 (+1%)

l2_block_building_time_in_ms
20,125
80,000
322,283

l2_block_rollup_simulation_time_in_ms
16,586
66,057 (-1%)
266,324

l2_block_public_tx_process_time_in_ms
3,508 (+1%)
13,870 (+1%)
55,711 (+1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
24,622 (-1%)
47,423

note_history_successful_decrypting_time_in_ms
2,139
4,184

note_history_trial_decrypting_time_in_ms
162 (+1%)
:warning: 225 (-34%)

node_database_size_in_bytes
3,423,173 (-6%)
:warning: 5,516,564 (+41%)

pxe_database_size_in_bytes
29,748
59,307

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
199
43,109
20,441

private-kernel-ordering
115 (+1%)
25,833
9,689

base-rollup
2,955
667,692
873

root-rollup
92.0 (+9%)
4,072
881

private-kernel-inner
260
64,516
20,441

public-kernel-private-input
171
25,203
20,441

public-kernel-non-first-iteration
168
25,245
20,441

merge-rollup
11.3 (+5%)
2,592
873

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
10,323
25,938

Wait why has this now been merged?
see: https://github.com/AztecProtocol/aztec-packages/pull/3636#discussion_r1421612722

Wait why has this now been merged?
see: #3636 (comment)

Not to worry! This still isn't hooked up to anything real, it just runs a few new tests using Goblin. Sorry - poor communication on our part. When Cody said "this wont be merged" we were still thinking it wouldn't be. Since then we decided to do something more isolated very much for the purpose of getting it merged


Assorted improvements

I'm working on a FilePickerCtrl. Do you want a PR for this?
Resolves #11

Update
This has turned into an omni-PR for a lot of little improvements that I had to make in order use re-wx for my (private, proprietary) project. In the end it all worked out and the project was finished and deployed.
Widgets
New components:

FlexGrid
FilePickerCtrlOpen
FilePickerCtrlSave
DirPickerCtrl

Improved components:

ScrolledPanel
Button
ComboBox
ListCtrl
SpinCtrl
SpinCtrlDouble
Block

Core

Empty child lists are allowed.
The patch reconciliation can now correctly handle the case where the type of a child changes. (This is great news because this is where the real magic of a declarative TEA GUI really happens. This is why re-wx is a generation better than horrible static design domain-specific languages ). We still don’t have 'key' props for performance.
Layout() each Sizer once for each patch. Resolves #15

Ok @chriskiehl I added docs in supported-wx-components.md for all the changes I made. Now I swear this PR is finished.

@jamesdbrock this is awesome stuff!


Dep injection

This PR adds better dependency management, moves cursor functions to the cursor node, and exposes PlayerController Properties to the inspector panel.
lines 5 and 10 of PlayerController.gd:
export (NodePath) var placement_grid_path = "../PlacementGrid"
export (float, 0, 100) var movement_speed = 10.0

These changes expose to the main scene properties that a level designer will use to change the controller feel
Here is what that looks like in the inspector panel after PlayerController has been imported into the main scene:

@jonathandavidlewis and I worked out a pattern to both expose sub-scene properties and methods and import properties and methods from sub-scenes of the main scene, while respecting the principle of modularity. (thanks for pair coding with me Jonathan!) project/src/Player/PlayerController.gd is a great example of how we will be doing this going forward.

I think this merge should be squashed.


Allow headings to be aligned

Would it be possible to add an option for headings? You can align the base style and other block types, but headings don't have the option.
An option would be similar to this:
heading:
    h2:
        font_size: 16
        align: center

Definitely. Do we need to support alignment per level or just all headings with the same alignment? Also, what about the alignment for the Table of Contents heading? Should that be configured separately or part of the setting for headings? (currently it's coupled to the level-2 heading). Maybe it's time to split that out into toc -> title (like sidebar -> title).

Would be preferred if it was per heading level. I have some documents where levels 2-4 are center aligned and level 5 is left aligned.
I would be fine if the macro headers (TOC, table of figures, etc) were kept tied to level 2. I'm sure someone would disagree though.

Thanks for that input. That's exactly what I needed to know.

This is a duplicate of #343 and was resolved in 1.5.0.alpha.12.


Fix MySQL and PostgreSQL GitHub Actions

Fixes #3347
Changes proposed in this PR:

Replace webdrivers gem with selenium-webdriver gem (https://github.com/titusfortner/webdrivers states "If you can update to the latest version of Selenium (4.11+), please do so and stop requiring this gem.")
Disable rack-attack from throttling "/users/sign_in" path on Rails test environment
Address Faker deprecation warning NOTE: Faker::Internet.safe_email is deprecated; use email instead. It will be removed on or after 2023-10. (More here: https://github.com/faker-ruby/faker/pull/2733)
Small changes to enable existing tests to pass (here: https://github.com/DMPRoadmap/roadmap/pull/3375/commits/a5710adda20baa288f5a4451526d9f49de8c37ef)
Fix mysql.yml and postgres.yml workflows by removing duplicate node-version: statements

Looks good. Updating webdriver and getting rid of issues with Github Actions.


fix: remove unneeded type exports in mongodb instrumentation

Which problem is this PR solving?
fixes: #1190
Short description of the changes
Avoid leaking types from mongodb instrumentation by splitting types.ts into a public and internal file.
Added type Document to avoid that lib dom needs to be added in build.
change typescript config to exclude lib dom on default and add it only where needed (web plugins and AWS SDK).
Checklist

[ ] Ran npm run test-all-versions for the edited package(s) on the latest commit if applicable.

reverted the commit to remove lib dom from build. This worked fine in my local environment but in hoisting is done different so lib dom is needed everywhere.

I got this error with version 0.36.0
npm run build
> tsc

node_modules/@opentelemetry/instrumentation-mongodb/build/src/types.d.ts:49:27 - error TS2304: Cannot find name 'Document'.

49     command(ns: any, cmd: Document, options: undefined | unknown, callback: any): void;
                             ~~~~~~~~

Found 1 error in node_modules/@opentelemetry/instrumentation-mongodb/build/src/types.d.ts:49


Tres Leches Cake Symbol Update

Updating Symbol to be in compliance with Phantom Wallet.
I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Going to Resubmit Pull to confirm no delete.


doc: Updated paper status for KCC

This commit is to update the current status of the paper
that is submitted to KCC conference. The paper is finally published.
Signed-off-by: Geunsik Lim<EMAIL_ADDRESS>

:memo: Version: 1.20190225. Thank you for submitting PR #533. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://nnsuite.mooo.com/TAOS-CI/ci/repo-workers/pr-checker/533-201909061600130.21701788902283-6cc42aeabdbfbca1dc1cdda65fed91a83d3b60f7/report/misspelling_result.txt.


#MATH-1509: Implement the MiniBatchKMeansClusterer.

Coverage increased (+0.04%) to 90.559% when pulling cd7df89611d0d6e60f0133bb155894e391c8b3f8 on chentao106:feature-minibatchkmeans++ into 22373aeb76811aae77f581143e9fed34580316eb on apache:master.


Closes #40 Initial ADCOEQ vignette

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral family codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

[ ] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
[ ] Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
[ ] Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
[ ] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[ ] Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
[ ] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[ ] Address any updates needed for vignettes and/or templates
[ ] Update NEWS.md under the header # admiral<ext> (development version) if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
[ ] Build site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the Reference page.
[ ] Address or fix all lintr warnings and errors - lintr::lint_package()
[ ] Run R CMD check locally and address all errors and warnings - devtools::check()
[ ] Link the issue in the Development Section on the right hand side.
[ ] Address all merge conflicts and resolve appropriately
[ ] Pat yourself on the back for a job well done! Much love to your accomplishment!

Thanks for this! Some preliminary notes before review (feel free to ignore if still developing):

You'll need to add an entry in _pkgdown.yml so the vignette appears in the navigation bar.
Title is quite long, what about: Creating a Control of Eating Questionnaire ADaM
I would make the license text even more prominent - perhaps a "License" section right above the introduction.
In the intro section, please reference the Questionnaire ADaM vignette (see how ADVS template did it)
Ensure "admiralmetabolic" is inside curly brackets and backticks ({admiralmetabolic}) throughout for correct linkage.
Ensure "pharmaverse", dataset names and variables are also in backticks - see ADVS vignette.
tibble shouldn't be a required package as you use it only for internal examples
After "Required Packages", add "Programming Workflow" section - same as ADVS vignette. In general try follow ADVS vignette layout for consistency across the package.
For Read In Data section, mimic ADVS vignette there too - show any code for qs and dm/adsl
For unscheduled visits, is this approach likely to vary across studies? Should we specfiy this?
Not sure baseline and change from baseline sections are needed. Can we just reference admiral documentation?

And the most complex comment:
Can you leverage call_derivation() to make the code in the "scales and scores" section more efficient. I give an example below for two parameters and then you can generalise:
adcoeq3 <- adcoeq2 %>%
  call_derivation(
    derivation = derive_summary_records,
    variable_params = list(
      params(
        filter_add = (PARAMCD %in% c('COEQ09','COEQ10','COEQ11','COEQ12','COEQ19')),
        set_values_to = exprs(
          AVAL = mean(AVAL, na.rm = TRUE),
          PARAMCD = "COEQCRCO",
          PARAM = "COEQ - Craving Control"
      ),
      params(
        filter_add = (PARAMCD %in% c('COEQ03','COEQ13','COEQ14','COEQ15')),
         set_values_to = exprs(
           AVAL = mean(AVAL, na.rm = TRUE),
           PARAMCD = "COEQCRSW",
           PARAM = "COEQ - Craving for Sweet"
       )
    ),
    dataset_add = . ,
    by_vars = exprs(STUDYID, USUBJID, AVISIT, AVISITN, ADT, ADY, PARCAT1, TRTSDT, TRTEDT, TRT01P, TRT01A)

Hi Kathrin,
Thanks for putting this up so quickly.
Few comments:

Title could be "Creating Control of Eating Questionnaire dataset"
Are we considering imputing baseline values in case the values are missing at baseline visit. Meaning if the participant does not respond to the questionnaire at the baseline visit but responds to the questionnaire at subsequent visits, then do we impute the values? Or leave it as it?
the derive_summary_records part can be written like a function/macro and called for the different PARAMs
Is there a requirement of a derived "Total Score" row? I have not worked on this particular questionnaire but in some other questionnaires, there are some derived rows for either a "Total Score" or an "Index Score".
The BASE, CHG, PCHG variables wouldn't be required unless there are some derived "Total Score" or "Index Score".
Same for the AVALCATy variables as well.
Hope towards the end of the code, we just ensure that all the required variables are kept, and other variables are dropped.

Thanks for your comments, both!
@manciniedoardo
I updated the code for most of your comments apart from these:

"For unscheduled visits, is this approach likely to vary across studies? Should we specfiy this?"

I guess it is up to the user how they want to use unscheduled visits - just like in all other ADaMs in general.

"Not sure baseline and change from baseline sections are needed. Can we just reference admiral documentation?"

I agree that we could also refer to the admiral documentation, but then what do we put in this vignette apart from the 4 subscale derivations? I left the code in for now.

"Can you leverage call_derivation() to make the code in the "scales and scores" section more efficient."

I tested this approach and the downside is that it does not include the original items anymore, but ADCOEQ should be a combination of original plus derived parameters. That's why I left the code as it was for now.

@Sonali-netizen
I made a few updates.
To some of your points in particular:

"Are we considering imputing baseline values in case the values are missing at baseline visit?"

I think imputation of missing data is a general topic and not specific to this questionnaire.

"Is there a requirement of a derived "Total Score" row?"

The CoEQ does not have an overall Total Score, but only the four derived subscales as I derived them in this code.

"Hope towards the end of the code, we just ensure that all the required variables are kept, and other variables are dropped."

The last dataset in the current code only contains the ADSL variables kept at the beginning, the QS variables and the newly derived ADaM variables.

Thanks for your comments, both!
@manciniedoardo I updated the code for most of your comments apart from these:

"Can you leverage call_derivation() to make the code in the "scales and scores" section more efficient."

I tested this approach and the downside is that it does not include the original items anymore, but ADCOEQ should be a combination of original plus derived parameters. That's why I left the code as it was for now.

What do you mean by this @kathrinflunkert? I think it should be possible to implement as in principle call_derivation() is a shorthand for your code so we shouldn't observe differences. Maybe you can share the problematic code? Thanks.

"Can you leverage call_derivation() to make the code in the "scales and scores" section more efficient."

I tested this approach and the downside is that it does not include the original items anymore, but ADCOEQ should be a combination of original plus derived parameters. That's why I left the code as it was for now.

You need to use a dot in both dataset and dataset_add to make it work properly. Here is the working example:
adcoeq3 <- adcoeq2 %>%
  call_derivation(
    dataset = .,     # <--- This cannot be omitted if you also use the dot somewhere else
    derivation = derive_summary_records,
    variable_params = list(
      params(
        filter_add = PARAMCD %in% c("COEQ09", "COEQ10", "COEQ11", "COEQ12", "COEQ19"),
        set_values_to = exprs(
          AVAL = mean(AVAL, na.rm = TRUE),
          PARAMCD = "COEQCRCO",
          PARAM = "COEQ - Craving Control"
        )
      ),
      params(
        filter_add = PARAMCD %in% c("COEQ03", "COEQ13", "COEQ14", "COEQ15"),
        set_values_to = exprs(
          AVAL = mean(AVAL, na.rm = TRUE),
          PARAMCD = "COEQCRSW",
          PARAM = "COEQ - Craving for Sweet"
        )
      )
    ),
    dataset_add = .,
    by_vars = exprs(STUDYID, USUBJID, AVISIT, AVISITN, ADT, ADY, PARCAT1, TRTSDT, TRTEDT, TRT01P, TRT01A)
  )

Or alternatively you can omit dataset argument but use adcoeq2 explicitly in dataset_add.

@kathrinflunkert can we remove draft status now?

Looks good to me too. Thanks @kathrinflunkert 👍🏻


Throw error in case of step value is NaN

This should resolve #226

Pull Request Test Coverage Report for Build 319

4 of 5 (80.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.6%) to 99.429%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/convert-expression/step-values-conversion.js
4
5
80.0%

Totals

Change from base Build 300:
-0.6%

Covered Lines:
272

Relevant Lines:
273

💛  - Coveralls

Oh yeah, I will add a test case for this...

@niftylettuce - care to review? :)

@node-cron Care to review?


FYI: Repo updates

I added a spec draft in the main branch. I preserved the original text in the preserved branch, see the diff here.

The updates look great! LGTM.


support syntax = "proto3" in protostuff parser

feature request

+1

@jnorthrup do you have ideas what is expected date for final release? current release is only alpha-2

it's live in grpc ( http://grpc.io )
On Thu, Mar 19, 2015 at 3:36 PM, Kostiantyn Shchepanovskyi <
<EMAIL_ADDRESS>wrote:

@jnorthrup https://github.com/jnorthrup do you have ideas what is
expected date for final release? current release is only alpha-2
https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-2
—
Reply to this email directly or view it on GitHub
https://github.com/protostuff/protostuff/issues/112#issuecomment-83788076
.

https://github.com/jnorthrup/prautobeans package uses the protostuff parser visitors  fwiw

@jnorthrup
Parser for proto3 is 50% ready - https://github.com/kshchepanovskyi/proto-compiler
It is based on ANTLR4. You can check tests to see what is already supported.

You can check new parser that supports proto3 here: https://github.com/protostuff/protostuff-compiler
Now it is in active development.


Broken Java Doc link in README

The Java Doc link under this section of the README goes to https://javadoc.io/org.firstinspires.ftc, which fails with an error " /org.firstinspires.ftc is not valid". Instead, it should link to https://javadoc.io/doc/org.firstinspires.ftc (note the /doc in the url preceding /org.firstinspires.ftc).

Oh good grief.  That makes me so unhappy...

At least it's correct over here: https://github.com/FIRST-Tech-Challenge/FtcRobotController/releases/tag/v7.0

I've now checked the Javadoc links in the wiki as well, and while they work, they are out of date. The Javadoc links here and here still point to https://first-tech-challenge.github.io/SkyStone. The link here points to       http://ftctechnh.github.io/ftc_app/doc/javadoc/index.html.

I've now checked the Javadoc links in the wiki as well, and while they work, they are out of date. The Javadoc links here and here still point to https://first-tech-challenge.github.io/SkyStone. The link here points to http://ftctechnh.github.io/ftc_app/doc/javadoc/index.html.

I've fixed these two entries.  The main page readme will be fixed with the next release.

Thanks for updating those two entries, however there is still an outdated wiki entry here.

Thanks for updating those two entries, however there is still an outdated wiki entry here.

Appreciate that last one, now fixed.

The readme fix is in progress for the next release.


fix(ci): coverage report generation for k8s_env tests

Purpose of PR?:
Fixes https://github.com/kubearmor/KubeArmor/issues/1758
Does this PR introduce a breaking change?
No, it changes Ci step
If the changes in this PR are manually verified, list down the scenarios covered::
N/A
Additional information for reviewer? :
The main purpose of gover is to concatenate multiple cover profiles into a single file. We dont need to do this as ginkgo already stored the cover profile in a single file (by default coverprofile.out).
The PR adds a flag in ginkgo test command to generate test profile for every package in the github.com/kubearmor/KubeArmor/tests . The reason to use full path is a bug in ginkgo when using relative path. It is supposedly fixed but using the relative path didnt work in our case (ref: https://github.com/onsi/ginkgo/issues/1161#issuecomment-1462585824)
Checklist:

[x] Bug fix. Fixes https://github.com/kubearmor/KubeArmor/issues/1758
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] PR Title follows the convention of  <type>(<scope>): <subject>
[ ] Commit has unit tests
[ ] Commit has integration tests

Hi @DelusionalOptimist
Can u please review this
If approved, this can be extended to systemd test as well

might fix https://github.com/kubearmor/KubeArmor/issues/845


PSAvoidUsingPlainTextForPassword is overzealous and wrong

I have this parameter in one of my functions:
        # The user name to fetch roles for
        [Parameter(Position=1, Mandatory=$True, ValueFromPipelineByPropertyName=$true, ParameterSetName='ByName')]
        [string]$AuthenticatedUser,

It causes a Warning:
PSAvoidUsingPlainTextForPassword: Parameter '$AuthenticatedUser' should use SecureString, otherwise this will expose sensitive information. See ConvertTo-SecureString for more information.

This isn't a password. It's a USER NAME. Go Away.

This is due to the way the rule has been built as it looks for "Auth" in any of the parameters and if it is of a string type will throw this Warning
However I will submit a PR to remove this as I agree that Auth shouldnt really be in list of keywords it searches for - the rest however I think are about right

Thanks for the fix, Ryan.


Deepgram Transcript issue

I think the transcript is not clearly divided into chunks.
So some of the chunks take too long to check violation using openai.
Most important thing is to set the appropriate size for each chunk

Okay, will fix it


Support Importing Scans from vuls.io

Is your feature request related to a problem? Please describe
A clear and concise description of what the problem is.
I want to be able to ingest vuls.io findings into DefectDojo.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Ex: As a < role >, I want < some goal > so that < some reason >.
Describe alternatives you've considered
I can ingest data from alternative sources, but this tool support analysis of application dependencies, container dependencies, and operating systems for vulnerable packages which we are currently assessing in our environment.
Additional context
Add any other context, screenshots, sketch, code snippet, etc. about the feature request here.

Up, this should be very nice.


deprecate/fix [ansible] galaxy services

This PR implements the proposals from https://github.com/badges/shields/issues/9631#issuecomment-1753494195

deprecate ansible galaxy collection name
deprecate ansible galaxy quality score
deprecate ansible role name
deprecate ansible role downloads and replace with a new (but non-backwards-compatible) ansible role downloads badge

I'm going to go ahead and merge this one. The existing ansible downloads badge is showing incorrect data.


fix: publish config

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


test: fix test setup

:tada: This PR is included in version 2.1.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Dev

Few corrections and changes made for the new Academic year 2023-2024.
List of changes :

➕ Secretary Role
➕ Bachelor Cyber
🔁 "Big Data" > "Développement Logiciel"
🔁 Form : updated lv2 options
✅ Typos

Some welcome updates, the user.js "roleCount" should get a refactor at some point... Looks fine to me, no issues that come to my mind. Sigma should create the roles at reboot. "Big Data" role may need a manual delete.

Concerning roleCount, I planned on possibly reworking the entire association module, but that will be one of the main things to change. And yes, that could be great if Sigma generates all classes roles at boot, I'll add it to the to-do list.


update portfolio

add projects and make the UI more user friendly as well as pick a different background colour

done


No wg-autostart command

Wireguard works very well, but I'm missing the wg-autostart command. With wg-quick up wg0 the tunnel comes up.
user@Server:~# sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add <IP_ADDRESS>/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add <IP_ADDRESS>/24 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add <IP_ADDRESS>/32 dev wg0;

Issue:
user@Server:~# sudo wg-autostart enable wg0
-ash: wg-autostart: command not found

Same problem with root. What am I missing?
DS918+
DSM 6.2.4-25556 Update 5
WireGuard-apollolake-1.0.20201221.spk

The wg-autostart command is only available if you compile from source (which you should probably do since you'll get a newer wireguard version that way).

Alright, thanks for your quick response.

The wg-autostart command is only available if you compile from source (which you should probably do since you'll get a newer wireguard version that way).
It will be available from the released packages once I make a new release.

Btw I wasn't able to compile it from source...
Instead I created a Task Scheduler, works pretty good.
Control Panel -> Task Schneduler -> Create -> Triggered Task -> User-defined -> User root and Event Boot-up -> Task Settings:
User-defined script:
bash wg-quick up wg0


Scrolbar drag interaction fidelity

The current implementation of the draggable scrollbar has a few quirks.

The longpress gesture takes 500ms (since that is the default for flutter). But on native it seems much faster, almost instant even.
From my testing it seems that the value should be somewhere between 50 and 150ms. It might even be that it just differentiates between a drag and a tap down.
I was able to change this value by adding a deadline field to the constructor of LongPressGestureRecognizer which I set to the values 50-150.

The current implementation also has a drag from the right gesture, I haven’t been able to reproduce this on a native iOS 13 device. Even with my apple pencil on the iPad pro it does not work. However, on the sim it ‘seems’ to happen. This is possibly just because the long press gesture is so short and thus already detected which gives the impression of the drag from the right working.

I think I'm on board with this approach to correct this.  Add a parameter like deadline to LongPressGestureRecognizer, then set it to ~50-150ms in CupertinoScrollbar.  I'll ask around if anyone has had a reason to tweak the long press threshold before.

I'm planning to try this out on a physical device tomorrow.  If it seems like it's just an accidental long press, it will be really easy to just remove the drag-from-right functionality.

I agree that swipe-in-from-right is a ruse!  I played around with a physical iOS 13 device and it seems like it is probably just activating the longpress method.
I think we should remove swipe-in-from-right and adjust the timing of longpress.  We should try out just using a tap or something first, but if that doesn't work out ok then I think something like deadline would be nice.

Closing with https://github.com/flutter/flutter/pull/41799.


Conditionalize CI steps requiring secrets

Fixes #3677.
Follow-up to #3680 which this PR builds on.
The problem with #3680 (I think?) is that it disables secrets (so, coverage reporting and the Cypress dashboard) even for PRs made by org members / from within the repository. We want a way to still enable those as easily as possible when we see well-meaning PRs. One option is to add a label on the PR to mark it as trusted. I would also like to check if the author of the PR is an org member (in which case we would not have to label the PR manually) but I haven't found the syntax for that yet.

I am merging this without review as this change on the CI cannot be tested without being merged. Happy to revert if there are concerns.

It looks like the syntax I tried to introduce conditions is incorrect so I reverted this change.


Umbrella Chart Configuration for Azure AKS

This PR performs the testing of dim wallet integration with the tx-umbrella components for the tx-community days event and contains Azure configuration values file:

Added values-test-data-exchange-azure.yaml file with Azure AKS cluster configurations and dim wallet integration

Description

Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[ ] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[ ] Copyright and license header are present on all affected files

Most of the changes made in this PR, come from 125. Wouldn't it have been better to have waited for that PR to merge, since it is already checked and tested, and make the PR later, adding only the Azure test stuff?

Most of the changes made in this PR, come from 125. Wouldn't it have been better to have waited for that PR to merge, since it is already checked and tested, and make the PR later, adding only the Azure test stuff?

Thats actually a good idea, I have added the azure specifc values file.

We need to wait until #125 is merged.
I will propose a change here, that you can configure the "base url " of azure of any cloud once and then it will deploy in this "sub-integrate"

What is missing here?

What is missing here?

I think the branch is not updated with the main.

@saudkhan116 Could you please provide a feedback on this PR? The base branch release/R24.08 is obsolete btw.

@saudkhan116 Could you please provide a feedback on this PR? The base branch release/R24.08 is obsolete btw.

I think the branch needs to be updated, and the base branch should be changed. Should I sync it with main?

Hey @saudkhan116.
This PR includes several outdated elements that have already been merged in other PRs.
In my view, the most significant aspect here is the inclusion of the values file for the Azure AKS connection. It would be great to have this file, as it would allow us to test deployment on the server, which would be incredibly helpful. 😊


Add column error while migrating

sqlite exec result is SqliteException(1): SQL logic error   Causing statement:  ALTER TABLE categories ADD COLUMN pomo_enabled INTEGER NOT NULL DEFAULT 0 CHECK (pomo_enabled IN (0, 1));. But the sql is right.
Code:
Table
@DataClassName('Category')
class Categories extends Table {
  TextColumn get sid => text()();

  BoolColumn get pomoEnabled => boolean().withDefault(const Constant(false))();

}

Migration
await m.addColumn(db.categories, db.categories.pomoEnabled);

error log
E/flutter (31478): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: SqliteException(1): SQL logic error
E/flutter (31478):   Causing statement: ALTER TABLE categories ADD COLUMN pomo_enabled INTEGER NOT NULL DEFAULT 0 CHECK (pomo_enabled IN (0, 1));
E/flutter (31478): #0      DatabaseImpl.execute (package:sqlite3/src/impl/database.dart:129:9)
E/flutter (31478): #1      _VmDelegate._runWithArgs (package:drift/src/ffi/database.dart:204:11)
E/flutter (31478): #2      _VmDelegate.runCustom (package:drift/src/ffi/database.dart:214:11)
E/flutter (31478): #3      _BaseExecutor.runCustom.<anonymous closure> (package:drift/src/runtime/executor/helpers/engines.dart:109:19)
E/flutter (31478): #4      _BaseExecutor._synchronized.<anonymous closure> (package:drift/src/runtime/executor/helpers/engines.dart:51:22)
E/flutter (31478): #5      new Future.sync (dart:async/future.dart:296:31)
E/flutter (31478): #6      Lock.synchronized.callBlockAndComplete (package:drift/src/utils/synchronized.dart:17:21)
E/flutter (31478): #7      Lock.synchronized.<anonymous closure> (package:drift/src/utils/synchronized.dart:21:35)
E/flutter (31478): #8      _rootRunUnary (dart:async/zone.dart:1436:47)
E/flutter (31478): #9      _CustomZone.runUnary (dart:async/zone.dart:1335:19)
E/flutter (31478): <asynchronous suspension>
E/flutter (31478): #10     migration9to10.<anonymous closure>.<anonymous closure> (package:timez/src/data/db/migrations/migration_9_10.dart:8:7)
E/flutter (31478): <asynchronous suspension>
E/flutter (31478): #11     DatabaseConnectionUser.transaction.<anonymous closure>.<anonymous closure> (package:drift/src/runtime/api/connection_user.dart:438:26)
E/flutter (31478): <asynchronous suspension>
E/flutter (31478): #12     DatabaseConnectionUser.transaction (package:drift/src/runtime/api/connection_user.dart:431:12)
E/flutter (31478): <asynchronous suspension>

lib
  drift: ^1.2.0
  sqlite3_flutter_libs: ^0.5.0

It seems sqlite not support CHECK. When i remove the CHECK (pomo_ask_before IN (0, 1)), everything works fine.

I couldn't reproduce this issue locally. The same ALTER statement with the CHECK works fine for me. We're also generating CHECK in CREATE TABLE statements, so I don't think it's about that probably.
Can you the exact version of sqlite3_flutter_libs that you're using (take a look in pubspec.lock)?

@simolus3
  sqlite3_flutter_libs:
    dependency: "direct main"
    description:
      name: sqlite3_flutter_libs
      url: "https://pub.flutter-io.cn"
    source: hosted
    version: "0.5.3"

I created a new Demo project and can still reproduce the problem.
Demo: https://github.com/T-Oner/drift_debug/
Branch v1 is database version 1, branch v2 is database version 2

Thank you for the helpful repro! Previously I've only tested this with the default sqlite3 coming with my OS, but I can reproduce this with the compile-time options used by sqlite3_flutter_libs.
After some trial and error, I've found that the SQLITE_DQS=0 compile-option (which is recommended by sqlite3) is causing this. I don't really understand why, so I've asked in the forum. Let's see if this is a sqlite3 bug or if I'm overlooking something that would need to be changed in drfit.

I could be way off here, but in the past when modifying sqlite tables adding new fields (not drift specific), sqlite only allowed new fields to be added at the end of the field list, shuffling fields around the only way I could do it reliably was to rename the table, create a new table with the existing name and the new field structure and then copy the data across, this was a few years back so this may not be a problem anymore and may not be related to this issue. Sorry if it is unrelated.

Congrats, it looks like you found a bug in sqlite3! This is only the second time I've seen this happen, sqlite3 is remarkably stable.
I will close this issue as it's not a bug in drift.

sqlite only allowed new fields to be added at the end of the field list

Right but isn't that what ADD COLUMN is doing? It doesn't look like this is about ordering.


Use multi-column layout for packaging status badge

So it takes less space, demo: https://github.com/messense/ruff/tree/repology-multi-column#installation

Not ideal for mobile devices, but I’ll let Charlie decide how much of a concern that is.

IMO it's not too bad on mobile devices, maybe 2 or 3 columns can be better.

I think I'm gonna leave this as-is just because I find the multi-column harder to parser. I'll move it to the bottom of the section though.


I can only get a square ripple

I can not get a circle ripple in my project!
I just change the "custom class" to MKTableViewCell in the storyboard and it can only perform a square ripple. Same issues in TextField.
But if i copy one from your storyboard directly, it works.

@Huxpro : please give me a link to download your code.

https://github.com/Huxpro/MKTest
Thankyou!

@Huxpro Thank for your reporting. I have just updated my code. Please pull the new source.

Thx it works now!


Added REST endpoint for getting entries by their app ID

:tada: This PR is included in version 1.11.0 :tada:
Your semantic-release bot :package::rocket:


Add options to show dates (esp. Due Date) as relative ("Today"/"2 days from now"/"2 weeks from now") on each item

Feature Request
Description:
In the list item view, it would be helpful to see each item's Due Date as a relative date, relative to today. It would still be stored as a yyyy-mm-dd date in the file, but it would be displayed as a relative date.
The benefit is that it would be easier to identify intuitvely and quickly what items are due soon.
Implementation Details:
Maybe this could be a setting in the settings?

@DeflateAwning a first proof of concept can be found in this pre-release. It is based on what the library, which is taking care of the date processing in sleek, can do out of the box without a lot of configuring. The function needs to be turned on in the settings. Let me know what you think.

@ransome1 I've tested this a bit and the following pops up for me

Can it be configured to never go below day precision. With todo.txt not having a time component "in 14 hours" feels worse than "in 1 day" (or ideally "tomorrow")
Could it switch to show the YYYY-MM-DD format on hover?
When it's further than a couple weeks in the future it'd be more relevant to show the date instead imo, but maybe human friendly "May 24" (or "June 25, 2025" for different year)

Agree with the hours comment; "yesterday" and "tomorrow" are the way to go imo.
Hover could be cool, but not MVP.
Agree with the distant future thing (maybe 30 days is the threshold); also not MVP though.

The way this works out is a little quirky too. Would be fantastic if it could be grouped by the way the string appears though, as it makes a lot of sense. Filtering to "stuff due 4 months ago" is way more useful than picking out specific dates.

I think this is the point where we need to admit we need a proper thought through concept for this.

I mean, I actually think we're on the right track with it, and I think this is already more useful to me than the old way.
If these things happened, I'd say it's completely valuable:

Make it so that hours never show. "yesterday", "today", and "tomorrow" are the only values.
Group together all buttons with the same "a month ago" and "2 months ago" text in the filters, instead of keeping them all separate.

What sort of concept were you thinking?

This is beautiful, and was exactly what I was envisioning. This may be even better than my date range filter request (#578). Well done!

It still needs quite some refactoring and even some fixing. For instance using the attributes in the todo list, does not work yet. Feel free to incorporate it into your daily usage and let me know what else needs improvement.

Very nice.
In line with last and next week I'd like to propose "this" in variants:

this week
this month

We can enhance the date concept a little bit and make it work like this:

Oh, well. It was just an idea.
I thought those "drawers" were hard-coded filters

No, it's fully dynamic. Let's see what I can do about it.

@rzw @DeflateAwning @strannik46 @swantzter I continued working on this feature and can use some testing and feedback: https://github.com/ransome1/sleek/releases/tag/v2.0.12-rc.3

RC3 installed. I will be using "this week" quite frequently and will give feedback.
What I noticed right upfront: "this month" is not March but March starting from tomorrow

What I noticed right upfront: "this month" is not March but March starting from tomorrow

Thanks for the hint, fixed it.

The shown value seems to be off by 1. For example, an item with a due date of March 1 was shown as being 4 days ago (today on March 4), but it should be shown as 3 days ago.
Feature looks good though. Nice addition! :smiley:
For now this is what I found. I'll see if I can test some more.

Logically it's also not consistent to have in 20 days describe a specific date while in 1 year is a period.

The way it works right now is for us to define some attributes by hand (except for overdue, this has been done more or less) and then as for the rest we need to decide if either:

we show all future dates, that don't fit into our definition, as actual dates YYYY-MM-DD
or use the dayjs, the library we use in sleek for date operations, to return friendly dates.

With option 1. we will most likely dissapoint users who have many todos in the future and will then face lot's of attribute button.
With option 2. we will have the advantage of some sort of grouping, but the logic behind it comes from dayjs and as you said, might lack consistency from time to time. I am happy with option 1. since I think having many dates in the far future and wanting those to be grouped, might be rather an edge case.

Otherwise one has to look out for the last red dots which is not very elegant.

This I don't fully understand, can you elaborate please?

Just have calendar dates in the attributes with the three exceptions mentioned above. Predefined filters with weekday and month logic (see list above) would be nice but aren't vital.

It is then just a matter of time, before others will ask to have it implemented in the list itself as well as in the groupings of the list too.
Anyhow, it currently looks like this:

Otherwise one has to look out for the last red dots which is not very elegant.

This I don't fully understand, can you elaborate please?

Well of course if you know today's date... ;-) Otherwise: Everything after tomorrow has black dots. Before that dots are red. So selecting today without human friendly dates means look for the last two red dots.

I'm fine with everything you find suitable. BUT if these friendly dates are at the cost of breaking filtering possibilities I'd  rather miss human friendly dates than filtering
due: > yesterday && due: < tomorrow+6d is broken
due: > yesterday && due: < tomorrow which returns today, works.

Well of course if you know today's date... ;-) Otherwise: Everything after tomorrow has black dots. Before that dots are red. So selecting today without human friendly dates means look for the last two red dots.

The color coding here is connected to the notification threshold in your settings. If a todo is below that threshold (basically the amount of days from today) a todo is let's say notification worthy and at the same time receives the red coding.

due: > yesterday && due: < tomorrow+6d is broken
due: > yesterday && due: < tomorrow which returns today, works.

I believe there is another issue where this has been raised. This feature had been developed by @zerodat and maybe he can give an update on this.

Ah, I see. I guess you're referring to #647.
Well that shouldn't be closed then, should it?

@bughunter2 @rzw @DeflateAwning @swantzter The latest progress can be found in this pre-release. Feel free to use it as daily driver and let me know, if it can be released.

Just downloaded v2.0.12-rc.4. Some thoughts:
Good idea to show 'last week' or 'next week' rather than the number of days!
Minor issue:
The 'due' text can be shown as 'overdue' even if the day falls within the 'last week' according to the calendar widget in Sleek. For instance, some regions/locales use Sunday as the first day of the week rather than Monday. That may be related, but I'm not sure. What I observed was this: I had a todo item with the due date set to March 3, 2024. At the time, it was March 16, 2024. The calendar widget in the due date picker shows March 3 in the same row as the other days of last week, but the item's due was shown as 'overdue' rather than 'last week'. If we picked March 4 (Monday), it was shown as 'last week'. The tested system had the default US region/locale settings where Sunday is the first day of the week.

Yeah, this sounds like an issue with the locale setting. Let me see, if I can reproduce this.

we show all future dates, that don't fit into our definition, as actual dates YYYY-MM-DD

With option 1. we will most likely dissapoint users who have many todos in the future and will then face lot's of attribute button.

I've installed RC4 and like the date attributes very much. I don't think the above is an issue.  You can't do it right for everybody. I can only recommend to use thresholds freely in order to avoid the issue of getting overwhelmed with attribute buttons.

Regarding:
due: > yesterday && due: < tomorrow+6d is broken
due: > yesterday && due: < tomorrow which returns today, works.

I find that this works for me in the current version of sleek.  That is, the first line is not broken, but properly returns todos scheduled for today or the next 6 days.  Please provide a more detailed example of how this fails for you, including test data and query string.

Bug Report
App Version: v2.0.12-rc4
Platform: Windows 10 (up-to-date)
Installation Method: portable/zip extracted
Expected Behavior:
Filter should do the math as described in wiki
Actual Behavior:
As soon as an operator (+) is entered interim results disappear and don't come back. The setting of "human friendly dates" has no effect.
Steps to Reproduce:
see description "Actual Behaviour"
Screenshots (on 2024-03-17):

A bug report in a feature request, this is new to me ;) Also we're losing focus here!
@rzw there is an open bug report on the search expressions: https://github.com/ransome1/sleek/issues/647

A bug report in a feature request, this is new to me ;) Also we're losing focus here!
@rzw there is an open bug report on the search expressions: #647

I apologize and agree. We're digressing in this thread but I didn't know where to put my comment. After all, it was a direct answer to @zerodat:

I find that this works for me in the current version of sleek. That is, the first line is not broken, but properly returns todos scheduled for today or the next 6 days. Please provide a more detailed example of how this fails for you, including test data and query string.

And regarding #647, I myself commented here:

Ah, I see. I guess you're referring to #647.
Well that shouldn't be closed then, should it?

I see it's been opened again. I am looking forward to testing RC5 today or tomorrow. Thanks for providing the new RC.

I see it's been opened again.

Yeah, there seems to be some kind of automation, which closes features once they had been added to a release.

Thanks for providing the new RC.

@bughunter2 @rzw @DeflateAwning @swantzter if you guys give me a thumbs up here, I will wrap this up and distribute it as v2.0.12.

Could you please check RC5 and give me a quick feedback, if this solves the issue on your end?

This was voiced towards @bughunter2 alias Jelle Geerts from the Netherlands (Surprise here regarding your stance). There is no right or wrong regarding Monday or Sunday being the first day of the week. But Religion aside Saturday and Sunday are called weekend not weekturn ;-). Since it's a matter of taste I'd look for something to hold onto and that's ISO 8601, making Monday the first day of the week.  But as long as I know I am easy with both.
Or...Time for another switch? Many calendars make this configurable. And after all, @ransome, you've programmed both already. ;-)

Could you please check RC5 and give me a quick feedback, if this solves the issue on your end?

This was voiced towards @bughunter2 alias Jelle Geerts from the Netherlands (Surprise here regarding his stance). There is no right or wrong regarding Monday or Sunday being the first day of the week. But Religion aside Saturday and Sunday are called weekend not weekturn ;-). Since it's a matter of taste I'd look for something to hold onto and that's ISO 8601, making Monday the first day of the week. But as long as I know I am easy with both.
Or...Time for another switch? Many calendars make this configurable. And after all, @ransome, you've programmed both already. ;-)

@rzw Not sure what you're surprised about? I don't consider myself religious, I just voiced my opinion about the matter because I value consistency. If the calendar widget shows a certain day as the start of the week (depending on the locale), then the whole application should be consistent with what is shown. That's all I meant to say. I don't really care otherwise.

@ransome1 Thumb-upped! :+1:  :slightly_smiling_face:

Quite a while ago, when implementing the date picker, we were struggling quite a bit with this. The initial idea was to decouple the 1st day of the week setting from the language with a dedicated setting. But the date picker was simply not accepting this in its latest version. The only thing it was receptive to, was the locale. This lead to the workaround that we have now, where the English setting represents en_US and hence Sunday as the 1st day of the week an English (GB) simply en_GB and Monday as the 1st day of the week. This is not my preferred solution, but at the time the only working one.
If we want to optimise this, we would need to make the date picker responding to a manual switch of the 1st day of the week. Maybe with more research and trial and error, this can be done somehow. But looking at the backlog and my current capacities (basically not existing at the moment ;)) it is one of many outstanding enhancements.
If you guys know somebody who knows hers or his way around JavaScript, HTML, CSS, Electron or React, I would be happy if you could mention this project.

@ransome1 Thank you for the explanation. So, by choosing either en_US or en_GB one is free to adjust the first day of the week. In my case english is not my native tongue but I choose english on my PC for an easier match between gui and manuals (sometimes only in english). I completely agree to categorizing this as an enhancement.
@bughunter2 I didn't understand what you were going for (receptiveness for locale). So, I was surprised to see someone from Europe opt for Sunday as beginning of the week.

@ransome1 Your stance is very understandable. Move on to more important things :+1:
@rzw Ah I see; guess I was thrown off by the reference to religion. I'm glad we understand each other better now.
Happy hacking! :smiley:

@bughunter2 @rzw I think I found a solution for the week start issue, which is not a workaround. In the latest pre-release you can find a setting which helps you defining the 1st day of the week. I also removed the duplicate English (GB) entry, since its sole purpose was to provide the 1st day of the week.
https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.1
Let me know if it works as expected.

Cool! Just as we kind of decided to move on, you fix the problem. Hats off.
While testing I found these behaviors:
If you launch the app for the first time, when the 'Language' setting has no value yet (shown as empty), the 'First day of the week' setting has no effect.
The first day of the previous week is never reported as 'last week' but as 'overdue' instead (as reported earlier). Maybe this is a simple off-by-one error? Like using < or > instead of <= or >= ? This happens regardless of the 'First day of the week' setting.

To add the thoughts I mentioned in #511 in the appropriate place:

sleek-2.0.12 shows "t: elapsed" instead of "t: 4 days ago" like in a previous pre-release. This is really not useful for threshold days since non-elapsed tasks are hidden anyway.
When changing the filter to show tasks with threshold dates in the future, I noticed that for tasks with "t:2024-04-01" it shows "t: next month".  I would rather prefer to see "t: in 5 days".

After reading the discussion in this issue, I understand that the rationale for the current approach is to group similar date ranges in the filter. Two thoughts about that:

Do the user friendly dates in the filter have to be the same as the user friendly dates in the badges inside the tasks? It might be useful to filter tasks that are due within the next week, but in the task list, "in 3 days" and "in 7 days" is a big difference.
I really do not understand the point of groups like "next month" which are calendar-based. The whole point of user friendly dates is that I don't have to remember the current date. "Next month" can mean something between 1 and 60 days. I would prefer user friendly dates based on rounding the relative number of days and showing it in the next bigger unit. This is also the case for the examples given in the issue title ("2 days from now"/"2 weeks from now").


npm run dev doesn't expose wasm dependency's

Describe the bug
Hello, I installed box2d-wasm dependency and I'm trying to log it to see if it is in my project.
Here it is: https://github.com/Birch-san/box2d-wasm
What ended up happening when I try to log the dependency is I received a bunch of errors but the important part I believe is that if I look in the network tab I can see that Box2D.simd.wasm is giving me a 404 error.
This does not happen when I run npm run build and then npm run preview it is only happening if I use npm run dev.
When I use webpack there is a similar problem but webpack tells me that I have to add something somewhere and it solves the problem that something is this.
fallback: {
  "path": require.resolve("path-browserify"),
  "fs": false
}

In the node_modules/react-scripts/config/webpack.config.js
Reproduction
https://github.com/laycookie/WASM-Fluid_simulation
Steps to reproduce
npm create vite@latest (I selected react-ts)
npm i box2d-wasm
In the code, you paste and that's pretty much it.
import { useEffect, useState } from "react";
import Box2DFactory from "box2d-wasm";

function App() {
  useEffect(() => {
    Box2DFactory().then((box2D: typeof Box2D & EmscriptenModule) => {
      console.log(box2D);
    });
  }, []);

  return (
    <>
      <canvas width="800" height="600"></canvas>
    </>
  );
}

System Info
System:
    OS: Windows 10 10.0.19044
    CPU: (12) x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
    Memory: 13.39 GB / 31.93 GB
  Binaries:
    Node: 18.7.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.15.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (106.0.1370.47)
    Internet Explorer: 11.0.19041.1566

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

This is an issue with the box2d-wasm dependency. It's using the path nodejs module so it can't be used in the browser. If you want to polyfill that in Vite, you can install path-browserify and set resolve.alias: { path: require.resolve('path-browserify') }

resolve.alias

Thanks but if you don't mind can you tell me where specifically I should add resolve.alias: { path: require.resolve('path-browserify') }

Yeah the config location is correct, but you'd need require.resolve too. Something like:
import { createRequire } from 'module'

const _require = createRequire(import.meta.url)

// ...
    path: _require.resolve("path-browserify"),

Yeah the config location is correct, but you'd need require.resolve too. Something like:
import { createRequire } from 'module'

const _require = createRequire(import.meta.url)

// ...
    path: _require.resolve("path-browserify"),

Thank you but at least this code doesn't seem to fix the issue I get the same errors, did I do anything wrong?
import { createRequire } from "module";
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

const _require = createRequire(import.meta.url);

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      path: _require.resolve("path-browserify"),
    },
  },
});


AMQP-806: Simple Publisher Confirms

JIRA: https://jira.spring.io/browse/AMQP-806
Avoid complex infrastructure for simple use cases.

Merged as https://github.com/spring-projects/spring-amqp/commit/3da5931567b69af5e793ba41f3bf1cd41207457e