Update to Cake 3.0

Description

Builds against Cake 3.0 and targets .NET 6 and .NET 7.
Related Issue

Fixes #37
Fixes #38
Fixes #39
Motivation and Context

Support for running addin with Cake 3.0
How Has This Been Tested?

Compiled locally
Screenshots (if appropriate):
N/A
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@devlead What tests and documentation do need to be updated?


Fix method name in docs

This should be generateTemplatePreview and not getTemplatePreview.

What problem does the pull request solve?

Checklist

[x] I’ve used the pull request template
[ ] I’ve written unit tests for these changes
[ ] I’ve update the documentation (in DOCUMENTATION.md)
[ ] I’ve bumped the version number

[ ] in src/main/resources/application.properties
[ ] in pom.xml

I don't think we need to change the version number because there's no change to the code that people will be downloading from Maven. This change is only needed for the documentation.


MCDA documentation

Adds MCDA documentation including setting weightings examples, explanation of aggregation methods, how to set algorithm example and example using site selection separately from the ecological model.

Happy to adjust if there is too much mathematical detail for the MCDA aggregation method algorithms.

Can also add references if necessary


Unexpected top level domain for RAPL package. Not yet supported.

A "hello world" example throws an exception:
leon@blade:/tmp$ cat eit-test.py
#!/usr/bin/env python3
import time
from experiment_impact_tracker.compute_tracker import ImpactTracker
tracker = ImpactTracker('logdir')
tracker.launch_impact_monitor()
time.sleep(20)
leon@blade:/tmp$ python3 eit-test.py
loading region bounding boxes for computing carbon emissions region, this may take a moment...
 454/454... rate=667.16 Hz, eta=0:00:00, total=0:00:00, wall=11:24 CETT
Done!
experiment_impact_tracker.compute_tracker.ImpactTracker - WARNING - Gathering system info for reproducibility...
experiment_impact_tracker.compute_tracker.ImpactTracker - WARNING - Done initial setup and information gathering...
experiment_impact_tracker.compute_tracker.ImpactTracker - WARNING - Starting process to monitor power
experiment_impact_tracker.compute_tracker.ImpactTracker - WARNING - Datapoint timestamp took 5.817413330078125e-05 seconds
experiment_impact_tracker.compute_tracker.ImpactTracker - ERROR - Encountered exception within power monitor thread!
experiment_impact_tracker.compute_tracker.ImpactTracker - ERROR -   File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/compute_tracker.py", line 105, in launch_power_monitor
    _sample_and_log_power(log_dir, initial_info, logger=logger)
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/compute_tracker.py", line 69, in _sample_and_log_power
    results = header["routing"]["function"](process_ids, logger=logger, region=initial_info['region']['id'], log_dir=log_dir)
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/cpu/intel.py", line 134, in get_rapl_power
    "Unexpected top level domain for RAPL package. Not yet supported.")

Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/utils.py", line 68, in process_func
    raise e
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/utils.py", line 62, in process_func
    ret = func(q, *args, **kwargs)
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/compute_tracker.py", line 105, in launch_power_monitor
    _sample_and_log_power(log_dir, initial_info, logger=logger)
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/compute_tracker.py", line 69, in _sample_and_log_power
    results = header["routing"]["function"](process_ids, logger=logger, region=initial_info['region']['id'], log_dir=log_dir)
  File "/home/leon/.local/lib/python3.7/site-packages/experiment_impact_tracker/cpu/intel.py", line 134, in get_rapl_power
    "Unexpected top level domain for RAPL package. Not yet supported.")
NotImplementedError: Unexpected top level domain for RAPL package. Not yet supported.

Running on an i7-6700HQ with Ubuntu 18.04.04 LTS under Python 3.7.5 and experiment-impact-tracker 0.1.8 in Copenhagen.

This is difficult to debug as I don't have this chip. I was looking at maybe porting the RAPL code to use a better supported package. If you have time, can you see if this package works for your system and successfully measures CPU? https://github.com/powerapi-ng/pyRAPL
E.g., does this output any energy info:
`	import pyRAPL
pyRAPL.setup()

csv_output = pyRAPL.outputs.CSVOutput('result.csv')

@pyRAPL.measure(output=csv_output)
def foo():
	# Instructions to be evaluated.

for _ in range(100):
	foo()

csv_output.save()`

Sure:
leon@blade:~$ ll /sys/class/powercap/intel-rapl/
total 0
drwxr-xr-x 5 root root    0 Jun 11 09:31 ./
drwxr-xr-x 3 root root    0 Jun 11 09:17 ../
-rw-r--r-- 1 root root 4096 Jun 11 09:17 enabled
drwxr-xr-x 6 root root    0 Jun 11 09:17 intel-rapl:0/
drwxr-xr-x 3 root root    0 Jun 11 09:17 intel-rapl:1/
drwxr-xr-x 2 root root    0 Jun 11 09:17 power/
lrwxrwxrwx 1 root root    0 Jun 11 09:17 subsystem -> ../../../../class/powercap/
-rw-r--r-- 1 root root 4096 Jun 11 09:17 uevent

Hmm, that's strange, it seems like you have all the needed files. Does #17 fix your issue?

Yes. The first domain reported is PSys which e-i-t didn't support.


add function to compute custom name for errors plugin generated types

Description
Adds an option for the @pothos/plugin-errors plugin to customize how type names are generated.
This new option could be used like:
export const builderWithCustomErrorTypeNames = new SchemaBuilder<{}>({
  plugins: [ErrorPlugin, ValidationPlugin],
  errorOptions: {
    defaultTypes: [Error],
    defaultGetTypeName: ({ fieldName, kind }) => `${fieldName}${kind}`,
  },
});

The above would get rid of the Query|Mutation prefix that is added automatically to these types, in case users want to modify these.
Resolves https://github.com/hayes/pothos/issues/566
Docs screenshot:

@hayes let me know what you think of the approach, once we are ok with the general approach I can also add a similar option for the with-input plugin!

looks like type-checking the test server fails, I think it's failing to import the schema after it was refactored


changeOrientationForIOS8 has bug

The direction of my application is forced to be portrait and I put a textfield in the alertview contentview. When the keyboard is showing, the alertview will still reposition to the center of screen while I move the phone. The iphone I test is iphone5 with ios8.4.

Believe that I have the same issue, this happens regardless or orientation but is more pronounced in landscape (less space for keyboard and popup).
Hold your device vertically (like your monitor is), then tilt the screen back slowly so it starts to face the ceiling. The alertview will move down the screen behind the keyboard.
Issue is with 'changeOrientationForIOS8', on this line;
CGSize keyboardSize = [[[notification userInfo] objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue].size;
keyboardSize is always nil as it doesn't receive notifications for this key.
Just about to create a pull request for this as I've made the changes. Also, swapped out
UIKeyboardFrameBeginUserInfoKey for UIKeyboardFrameEndUserInfoKey, as that represents the final size of they keyboard.


using cp instead of mv, fix spelling of "listener"

Copying the scripts from the cloned repo instead of moving them, also: updating the spelling of the word "listener" in the success message.

Thanks for the PR — any reason in particular you copied the files instead of moving them?

Usually installer only copies file from archive/tmp folders to production system. Thus question should be 'any reason in particular you moved the files instead of copying them'.
Copying files allows to install directly from your local git clone directory.

Sorry I missed your question. I copied the files so that the clone of the git repo didn't have any changes.

Thanks for the clarification! Approved.


Issue with compilation in Android project: 'Could not create task' error - React Native DeepAR

Hey There,
I am currently working on an Android project using DeepAR and React Native. I'm encountering an error while trying to compile my project. The error message I'm getting is:
DeepAR: Execution failed for task ':tasks'. > Could not create task ':react-native-deepar:compileDebugJavaWithJavac'. > In order to compile Java 9+ source, please set compileSdkVersion to 30 or above.
I have already set compileSdkVersion to 33 in my project, and I couldn't find any issues related to this specific problem. Here are the relevant parts of my build configuration:
buildscript {
ext {
    buildToolsVersion = "33.0.0"
    minSdkVersion = 21
    compileSdkVersion = 33
    targetSdkVersion = 33

    ndkVersion = "26.1.10909125"
}}

I've checked the documentation and forums but haven't been able to resolve this. Can anyone point me in the right direction or provide insights on what might be causing this error? Any help would be greatly appreciated.
Thank you!

i solve this issue to make changes in
1.Project/build.gradlew
ext {
buildToolsVersion = "33.0.0"
minSdkVersion = 23
compileSdkVersion = 33
targetSdkVersion = 33
    // We use NDK 23 which has both M1 support and is the side-by-side NDK version from AGP.
    ndkVersion = "23.1.7779620"
}

2. nodemodule/react-native-deeper/android/build.gradlew

android {

compileSdkVersion safeExtGet('Deepar_compileSdkVersion', 30)
buildToolsVersion safeExtGet('Deepar_buildToolsVersion', '30.0.0')
defaultConfig {
minSdkVersion safeExtGet('Deepar_minSdkVersion', 23)
targetSdkVersion safeExtGet('Deepar_targetSdkVersion', 30)
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
}
}
lintOptions {
disable 'GradleCompatible'
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}

+1

I encountered a build issue with the react-native-deepar library due to the compileSdkVersion being outdated. The default value in the file node_modules/react-native-deepar/android/build.gradle was set to 29, which caused compatibility issues with the latest Android SDK.
Solution:
To resolve this, I updated the compileSdkVersion in the following file:
File: node_modules/react-native-deepar/android/build.gradle
android {   compileSdkVersion safeExtGet('Deepar_compileSdkVersion', 30)   ... }


Roles Missing in the new role documentation

Hi,
https://github.com/pivotal-cf/docs-pks/blob/247e5cd86a91d4961df03c59ad3dcf8809e398f3/gcp-prepare-env.html.md.erb#L26
In the roles mentioned Compute Viewer is missing. Earlier it was there for v1.0.2 where there was only one role for master as well as worker.
When the role is missing for Master, k8s cluster could be created, but k8s services like "kube-dns" has issue with bootstrapping hence throws error in creation.
Looking at the  kube-controller-manager logs, the missing google cloud service account privileges error is seen.
Thanks
Darshit Sanghavi

Thank you, @darshitsanghavi! We've added the missing role to the documentation in the following commit: https://github.com/pivotal-cf/docs-pks/commit/3bd9ab996eaae31190266df64b69ec63d1904deb


Guide and Documentations for FeatureBridge

We need to have a guide and documentation for FeatureBridge and for every method.
We need to include benchmarks and an overview to explain what FeatureBridge is all about.

Done.
Phase 2 is required to have an in-depth algorithm guide.


Training data and inclusion

Hi there,
I have noticed that JoyCaption sometimes skips image features I want the captions to talk about. I know I can fine tune it, but I am curious about where the training data came from and reviewing the training data might help explain to me why the model behaves this way.
Will you publish the training data set or will that always remain hidden?

All of the training data will be published (with images as hashes and urls where possible).  I'm working on getting the dataset organized (it's a complete mess at the moment), so expect it to be uploaded closer to a version 1.0 release.
Yeah, the model will miss features for a variety of reasons.  Finetuning will always be the best for improving that, but I'm working to get better instruction following into JoyCaption so that it can be guided by a prompt to focus on whatever specifically you want it to describe.

Thank you for responding, I'm looking forward to seeing the dataset. From a user perspective, using a torrent would be most convenient as it has hash checking included, but I understand if it's too large for that to be practical.


Cow: Watch headphonesdude.com

Cow requests the watch of the watch_keyword headphonesdude\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

headphonesdude\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Fix flakey title-append test

Fix my own flakey title-append test using waitFor introduced in #986.
Using an explicit delay is a last resort that we can avoid here.
Test URLs:

Before: https://main--milo--hparra.hlx.live/?martech=off
After: https://fix-title-append-flap--milo--hparra.hlx.live/?martech=off

UT fails due to "marquee > supports media credits > has a media credit with element content" that is broken on main.

FYI - the failing test is not related to this PR and is fixed by skipping in this PR:
https://github.com/adobecom/milo/pull/1006


Compatibility with create-react-app

What?
Rename scss files that are designed to work as CSS Modules to _{moduleName}.module.scss
or (maybe, may need more thought) include a second file called _{moduleName}.module.scss that composes _{moduleName}.scss
Why?
Create React App 2 now supports Sass and CSS Modules:

More styling options: you can use Sass and CSS Modules out of the box.
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html

Create React App has the convention that if you do:
import styles from "./button.scss";

It will treat button.scss as a normal SCSS file and append the styles to your stylesheet.
However, if you do:
import styles from "./button.module.scss";

It will treat button.module.scss as a CSS module and return an object to JS for class name lookup.
Consider the following:
import React from "react";
import styles from "./button.module.scss"; // works
// import styles from "govuk-frontend/components/button/_button.scss"; // doesn't work
// import styles from<EMAIL_ADDRESS>// works

const Button = props => (
  <button className={styles["govuk-button"]} {...props} />
);

export default Button;

Where button.module.scss is:
@import "~govuk-frontend/components/button/button";

.govuk-button {
  composes: govuk-button;
}

At the moment I have to create a mostly redundant file to make sure that _button.scss is picked up as a CSS module.
Using:
import styles from "govuk-frontend/components/button/_button.scss";

Imports the CSS file but does not treat it as CSS module, so this does not work.
I have created a fork of govuk-frontend and renamed _button.scss to _button.module.scss, so if you do the following:
import styles from<EMAIL_ADDRESS>

This makes govuk-frontend work with create-react-app out of the box.
You can try this out on the following sandbox:
https://codesandbox.io/s/w0x8xk5lk

(please do this for helpers such as objects/_main-wrapper.scss and not just components)

This looks really interesting, renaming them straight away would be a breaking change.
I wonder if we could have a build step that duplicates the original file with the different name, and deprecate the original file name for when we next do a breaking release?

https://facebook.github.io/create-react-app/docs/adding-a-css-modules-stylesheet
I wonder if we could consider this a general way for people to be able to use Webpack with our CSS?
So support it for general CSS Module usecase and then we'd support whatever framework people are using.

On a side note, once this is done, it would allow a file at src/components/button/Button.jsx that contains:
import React from "react";
import styles from "./_button.module.scss"; // works

const Button = props => (
  <button className={styles["govuk-button"]} {...props} />
);

export default Button;

😀

I think if you're a CSS Module user it already works, this is just specific to React Create App since they want to be able to support people just including raw CSS AND CSS Modules users so they use this naming convention.

I guess it's a CRA pattern but only in that they want to pass a regex to webpack, so this seems like a reasonable convention.
It appears there is some work to make this a wider standard: https://github.com/css-modules/css-modules/issues/229

Related https://github.com/facebook/create-react-app/issues/5687

angular-cli has the same pattern. see https://github.com/igloosi/govuk-frontend-angular-cli-example/tree/master/src/app/app-button

Neutrino also follows the *.modules.css pattern:

Pre-configured to support CSS Modules via *.module.css file extensions
https://neutrinojs.org/packages/web/
https://neutrinojs.org/packages/style-loader/
https://neutrinojs.org/packages/react-components/
https://neutrinojs.org/packages/vue/

If there are any pointers on how you see this being implemented I could look at contributing this myself.
The two main questions I have are:

where in the build process would we create the *.module.css version?
2.
I am pretty sure your CSS naming convention assumes that if you have an element with  .block__element--modifier then you should always have  .block__element on the same element.
In the css modules version, should we enforce this by making .block__element--modifier always compose .block__element?
e.g. in _header.module.scss:
@import "./header";

.govuk-header__link {
  composes: govuk-header__link;
}
.govuk-header__link--homepage {
  composes: govuk-header__link;
  composes: govuk-header__link--homepage;
}

We've spent time going over this with Alasdair and decided we won't support this directly in GOV.UK Frontend for now, if you'd like to see the details we've put together a proposal you can read..
Thanks for all your work on this.


Timestamping transcriptions?

Would it be possible to add some option to delimit the transcribed output as timestamp-prefixed lines, or some other mark/metadata when each word occurs in the source media?
This is the way I was thinking I could hack it, if there isn't any way to surface this from the lower-level implementation:

Split the audio into chunks of lineDuration seconds (where lineDuration is the number of seconds to elapse between each line, like 5 or 10).
Get the transcript for each of those spans of text.
To ensure no words are getting cut on the clip boundary, produce a transcript for the gapSpan long seconds of audio on either side of the cut boundary (where gapSpan is some amount of time we expect the transcription to become stable within: I would guess something like four seconds would probably be fine).

If the transcript of the seam section conflicts in its middle with the transcript of the two sections concatenated, replace the words (in roughly balanced proportion) at the ends of the lines with the transcribed words from the seam.

I see now that #211 links to a fork with word-level timestamps: it looks like someone still needs to submit a pull request?


xen: Fix assembler warnings in hypercall_page.S

Recent versions of gas emit a warning when the type of a symbol is
changed between incompatible types. DECLARE_HYPERCALL() does this
intentionally, so silence the warning using the method suggested in the
manual [1].
[1] https://sourceware.org/binutils/docs/as/Type.html#Type

Travis failures here are due to #477, merging this.


Organize and improve channel menu (left sidebar)

We should:

Add a new "Copy link to channel" option to the channel menu. For spectators, we can add the menu, and have this be the only option.
Organize the channel menu, like so:

New topic
Mark all messages as read / unread
Copy link to channel <- new option, see here

Channel settings
Pin channel to top
Mute channel
Unsubscribe

Change color

Change the "Channel settings" link in this menu to go to the /personal tab when the user does not have permission to modify the general settings.

CZO thread

@zulipbot claim


Global Pinning Phase 0

Tasks for global pinning, port from Swarm to BEE
Initial porting process, barebones for this phase 0
Tasks

[x]  Trojan chunk implementation porting as a standalone package in bee
[x]  take targets as arguments in download path
[ ]  logic to detect chunk as missing
[ ]  send a trojan chunk
[x]  inspect Bee project to find possible integration places
[ ]  create integration test issue for @svetomir
[x]  plan with @zelig and @nolash PSS porting

PRs

#
title
status

#429
Trojan chunk support
closed

#430
Add targets to query param on download path
closed

Hi guys, what is the status of this one?

It is done. We just have to merge. I need to check if i need to wait and merge in master or merge it right no in global-pinin-pss branch itself.

looks like done


[CT-1130] [Feature] Update Metric Spec With Clearer Names

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Technically a duplicate of this issue https://github.com/dbt-labs/dbt-core/issues/4325
Right now, we have two fields within the metric spec whose names don't perfectly match what they are trying to convey.

sql : this attribute represents the sql expression that will be aggregated. It can be a simple field (user_id) or more complicated (case when x > y then x else y end)
type : this attribute represents the calculation / aggregation method that we are performing on the expression.

Proposed Change
As such, I propose the following changes:

Renaming type to calculation_method.

Why calculation method and not aggregation method? This is because we do have some metrics that aren't aggregations. Specifically expression/derived metrics. Calculation method keeps the door open to other metric types in the future that also aren't technically aggregations

Renaming sql to expression

Alternatively we could call this measure - this would build off the prior art of a lot of BI tools.

Renaming expression type metrics to derived metrics

This was the top suggestion for name by the community. I have no strong opinions on this one so I will bow to the will of the community

 Old format
version: 2
metrics:
  - name: base_average_metric
    type: average
    sql: discount_total

    model: ref('fact_orders')
    label: Total Discount ($)
    timestamp: order_date
    time_grains: [day, week, month, all_time]
    dimensions:
      - had_discount
      - order_country

 New format
version: 2
metrics:
  - name: base_average_metric
    calculation_method: average
    expression: discount_total

    model: ref('fact_orders')
    label: Total Discount ($)
    timestamp: order_date
    time_grains: [day, week, month, all_time]
    dimensions:
      - had_discount
      - order_country

Let me know what y'all think!
Describe alternatives you've considered
Not changing this.
Who will this benefit?
Anyone who uses metrics!
Are you interested in contributing this feature?
Yep! Already scoping it out in a PR
Anything else?
No response

@callum-mcdata Thanks for taking charge of the Slack convo + issue + PR!


AtomicU8 is stable (and supported by the MSRV)

Apparently, crossbeam has MSRV 1.36, which includes AtomicU8. Hence the following comment is outdated:
https://github.com/crossbeam-rs/crossbeam/blob/2653a6cfe7f8756d27f53d51cc84fcabf5d1d549/crossbeam-utils/src/atomic/atomic_cell.rs#L796-L801
Considering that this comment legitimizes code that is officially UB, I propose that this should be fixed, if possible.

This very naive patch passes the tests:
-                let val = ptr::read_volatile(src);
+                let mut val = std::mem::MaybeUninit::uninit();
+                let mut val_bytes = val.as_mut_ptr() as *mut u8;
+                let mut src_bytes = src as *mut core::sync::atomic::AtomicU8;
+                let src_end = src_bytes.offset(std::mem::size_of::<T>() as isize);
+                let val = unsafe {
+                    while src_bytes != src_end {
+                            val_bytes.write((*src_bytes).load(Ordering::Relaxed));
+                            val_bytes = val_bytes.offset(1);
+                            src_bytes = src_bytes.offset(1);
+                    }
+                    val.assume_init()
+                };

We could try using larger loads like thomcc's tearcell does: https://github.com/thomcc/tearor/blob/c558f6105230a49bb79b8afe989194e7656fdda7/src/lib.rs#L122-L162 instead of a naive byte by byte copy.
However, when I asked for review in the community discord server's #dark-arts a problem with padding bytes was mentioned: reading uninit/padding memory with AtomicU8 is not documented to not be UB. No way to fix this without a new language primitive or the language allowing these reads for atomics. For example, for this program
use std::mem::MaybeUninit;
use std::sync::atomic::{AtomicU8, Ordering};

fn main() {
    #[repr(align(2))]
    #[derive(Debug)]
    struct WithPadding {
        _d: u8,
    }
    let mut x = WithPadding { _d: 3u8 };
    let x_p = std::ptr::addr_of_mut!(x);
    let mut y = MaybeUninit::<WithPadding>::uninit();
    unsafe {
        *y.as_mut_ptr().cast::<u8>() = (*x_p.cast::<AtomicU8>()).load(Ordering::Relaxed);
        *y.as_mut_ptr().cast::<u8>().offset(1) =
            (*x_p.cast::<AtomicU8>().offset(1)).load(Ordering::Relaxed);

        dbg!(y.assume_init());
        dbg!(std::mem::size_of::<WithPadding>());
    }
}

MIRI currently gives the following error (With -Zmiri-check-number-validity)
error: Undefined Behavior: type validation failed: encountered uninitialized bytes, but expected initialized plain (non-pointer) bytes
    --> D:\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\sync\atomic.rs:2570:24
     |
2570 |             Relaxed => intrinsics::atomic_load_relaxed(dst),
     |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered uninitialized bytes, but expected initialized plain (non-pointer) bytes

I have investigated the problem of such before (atomic-memcpy) and there are two main problems with the approach that uses AtomicU8.

reads and writes as AtomicU8 slice are very slow compared to volatile reads/writes.
safety requirements for transmutation to/from integers must also be met since copying is via integers.

For the first problem, p1478r1 has an idea that seems to handle it well, and atomic-memcpy implements a variant of it. (In some cases, it can generate asm equivalent to volatile read generates. See atomic-memcpy's readme and the implementation comments for more).
The second problem actually contains (as far as I know) 2 to 3 problems.

ptr2int2ptr transmutation (not cast)
partial copy of pointers
copy of partially or fully uninitialized integers as initialized integers

ptr2int2ptr transmutation was previously used as a hack to work around ptr2int2ptr cast, but this has recently changed and Miri now reports this case as UB.
The known fix to ptr2int2ptr transmutation problem is to transmutate pointers to/from MaybeUninit. Of course this way does not work when using std atomic types.
Even assuming that ptr2int2ptr transmutation is not a problem, the approach using AtomicU8 may cause problems with partial copy of pointers. (IIRC, Miri currently reports "unsupported operation: unable to turn pointer into raw bytes" error on this case)
This is usually not a problem for atomic-memcpy's approach, which reads and writes as slices of AtomicUsize at most depending on the alignment. (except for repr(packed) and similer things)
The uninitialized byte problem can never be resolved when using std atomic types.

Based on the above, I believe that the feature to read and write MaybeUninit<u{8,size}> atomically would fix most of the remaining problems. I can think of 3 solutions:

Rewrite https://github.com/rust-lang/rust/issues/58599.
Implement AtomicMaybeUninit in the standerd library. (by using new intrinsics  or inline assembly)
Implement AtomicMaybeUninit in the crates.io library. (I don't know any other way than to use inline assembly)

I have implemented the third (atomic-maybe-uninit), and I think it needs "audits from someone familiar with these platform-specific codes", "more platform support", and "methods optimized for the case like atomic-memcpy" (inline assembly prevents some optimizations) when use it in crossbeam.

ptr2int2ptr transmute problem could be mostly solved (as long no unaligned pointers are stored in #[repr(packed)] structures) by using AtomicPtr when a given memory location could potentially store a pointer - it's perfectly fine to store non-pointer values in a pointer. Not that it helps that much with other issues.


Update true-up review documentation.

Summary
Recently, some changes have been added to update the process for true-up review.
This change updates the instructions for sending Mattermost a true-up review report.
Ticket Link
MM-50030

Awesome! Thanks so much for this, @ConorMacpherson! I was under the impression that this was for v7.8. Could you confirm that it's live now?

Yep! Once it's merged it's live. I'll add a milestone and label to this. :)

Hey @ConorMacpherson  -- good initiative here.
We would want to maintain the documentation for the old process involving having to take screenshots, since the feature you've built will only be available for customers that have version 7.9 or newer.
We'd want to have something like, "For 7.9 and older..." and "For 7.9 and newer" sections

Thanks @johndavidlugtu! Makes sense, I'll add the old section back and update these changes to make sure they mention 7.9 tomorrow morning :)

Documentation for https://github.com/mattermost/mattermost-webapp/pull/11844


Fix zero plan_node_id for BitmapOr/And in ORCA

According to plannode.h plan_node_id should be unique across entire final plan tree. But ORCA DXL to PlanStatement translator returns uninitialized zero values for BitmapOr and BitmapAnd nodes. This behaviour differs from Postgres planner and from all other node translations in this class. It was fixed.
There are no regression tests in this PR as GP doesn't seem to have a SQL infrastructure to retrieve plan_node_id from a generated plan. I made some experiments with
create table t(a int);
insert into t select generate_series(1, 10000);
create index t_idx on t(a);

set debug_print_plan = on;
set client_min_messages = log;
set optimizer_enable_bitmapscan = on;
explain select * from t where (a < 10 or a > 9999) and (a > 0 or a < 10000);

but the result contained too much per-run specific information like OIDs and exact costs. So this method doesn't suit us for a current task.
Also there is no sense to use ORCA mini dump infrastructure as plans are constructed correctly. The problem is in post-plan translation outside of ORCA in gpopt module.

As ORCA is a part of GP repository and this problem affects 6X_SATBLE and master branches, this PR is made to master branch. Pivotal backport such commits to all affected stable versions itself.

Does this problem only affects Bitmap... nodes?

Does this problem affect only Bitmap... nodes?

Yes, I've checked all other nodes in CTranslatorDXLToPlStmt.cpp


CASMTRIAGE-6017: check prerequisites completion before upgrade

Description
The original CSM upgrade script does not check if the prerequisites script has been executed correctly. This PR ensures that prerequisites script has been completed before upgrade. It also makes sure that a chart upgrade failure in prerequisites script will cause the script to exit.

Checklist

[ ] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[ ] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[x] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.6

/backport release/1.6


DN resolution fails with service is linked to a servicealias.

Server version - Build from master
Steps to reproduce the problem:
Create services s1 , s2.
Create servicealias -s3 linked to s1 and s2.
Create service client1 and link this service to s3 with name say "mylink".
From containers of service client1, "mylink" does not resolve to s1 and s2.

Tested with master build from Dec 4.
DN resolution works when service is linked to a  service by providing a service alias name.


Utxos in a successful /transaction.submit but not yet mined should be excluded from account's available utxos

Copying over @pnowosie's explanation:

tx submitted to ch-ch
ch-ch publishes new block's hash in transaction on Ethereum
Watcher discovers the above Ethereum transaction
Watcher asks ch-ch of block for a given hash
Ch-ch responds with block which contains tx
Watcher processes block and includes tx in DB (here Watcher is Info-Api Watcher)

Latency:

Time needed for a block to be formed (~1 plasma block per Ethereum block)
Block publication transaction needs to be mined on Ethereum (depends on gas price and Ehereum blocks freq)
Then on Watcher side Ehereum event listener check interval
Network latency in Watcher -> Ch-ch
Block processing time (checking especially all signatures in large blocks takes a little)
DB insert

Because of this latency, the same utxo might be picked up by /transaction.create again before it is marked as spent by the first submission.
Need a way to keep track of utxos that are being processed.

This is a bit tricky though...because only the specific watcher that receives the /transaction.submit request would know such account related info. I think ideally it should be the responsibility of a layer on top of the watcher (eg. e-wallet) to handle account-related states, especially there are pending states.


Synchronize with libpod 1.6.1

Make python-podman compatible with libpod 1.6.1
libpod 1.6.1 is revision is f3ffda1e08f19e9a6a88484136b5eed76533f21a
Get diff with:
$ ./tools/synchronize.sh -b=f3ffda1e08f19e9a6a88484136b5eed76533f21a -i

For more infos about this previous command please see #71
Introducing:

GetContainersByStatus
HealthCheckRun
GetContainersByContext
GetContainersLogs
GetContainerStatsWithHistory
InitContainer
AttachControl
GetPodsByStatus
ImageExists
ContainerExists
ContainerCheckpoint
ContainerRestore
ContainerRunlabel
ExecContainer
ListContainerMounts
MountContainer
UnmountContainer
ImagesPrune
GenerateKube
ContainerConfig
ContainerArtifacts
ContainerInspectData
ContainerStateData
PodStateData
CreateFromCC
ReceiveFile
VolumeCreate
VolumeRemove
GetVolumes
VolumesPrune
ImageSave
GetPodsByContext
LoadImage
GetEvents
GetLayersMapWithImageInfo
BuildImageHierarchyMap

Some methods are for the development of Podman and should not be used.
List of ignored and not implemented methods:

CreateFromCC
GetLayersMapWithImageInfo
BuildImageHierarchyMap

When these changes will be merged then we need to release a new python-podman version 1.6.1:
$ git tag 1.6.1
$ git push --tags
$ # The previous command will launch the CI who will generate and publish the release 1.6.1 on pypi

When these changes will be merged and the tag published then I will do the same things for higher version (1.6.2, 1.6.3, etc... 1.7.0), to ensure that will only release the right delta between versions.

Hello @rhatdan
Are you (I mean the podman team) interested by these changes?
Please, let me know if we want to continue with these changes.
Thanks
PS: I hope you don't feel harassed, it's not my goal :)

These LGTM
Most of the team is concentrating on APIV2 which is a replacement for the varlink API.  And some effort is going into podman-py.

@jwhonce PTAL

@4383 Changes look good.  But travis shows we are having a dependency issue. Looks like we need a replacement for PyYAML. Do you have any suggestions on that?

@rhatdan If we drop RHEL7 support would be another way to resolve the dependency issue.

Thanks @rhatdan and @jwhonce for you feedback and sorry to disturb you during parallel effort.
Concerning the CI issue it's related to the support of py34, that I think could be dropped, so yes dropping the RHEL7 support which iirc isn't really an issue for podman (integrate to RHEL8) could fix the issue and reduce our footprint in term of python support.

Yeesh, tough to drop support for RHEL7/Centos7.  Do you know if those distros could get updated versions of python3, so they could use the tools?

Yeesh, tough to drop support for RHEL7/Centos7. Do you know if those distros could get updated versions of python3, so they could use the tools?

@rhatdan sorry no idea

@rhatdan: Do you know if those distros could get updated versions of python3, so they could use the tools?

Very easily, just yum install rh-python36 (assuming the required optional rpms have been enabled). Here's a blogpost (by RH no less) about the details.
Similarly on Centos7.

@4383 Do you want to add links to those blogs to the end of the README.md? Otherwise, I will.

@4383 Do you want to add links to those blogs to the end of the README.md? Otherwise, I will.

@4383 Do you want to add links to those blogs to the end of the README.md? Otherwise, I will.

@jwhonce: As you want, feel free to do it, I'm currently a little bit stuck on other topics.

@4383 I'll do an additional PR to update README.md after this merges.  LGTM, ready?

@4383 I'll do an additional PR to update README.md after this merges. LGTM, ready?

@jwhonce From my point of view yes it's ready, now you need to judge if  these changes seems ok for you.
Thanls

Do you think it's possible to merge these changes?
On tobiko we need some methods implemented by these changes.
We waiting for your feedback.


Increased jobs time limit and disk usage

Purpose

Increased HySDS jobs time limit to 1 day
Increased job's disk usage to 500 MB

Sorry for the typo. It's not updated.


Documentation is lacking

The documentation is a bit sparse. Perhaps add usage example?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 68aa4bac-d5ea-3a97-63fe-f699cf51f8ea
Version Independent ID: 9f377062-7a81-658e-90ea-a1c9bfd2f5e4
Content: DbEntityEntry.GetValidationResult Method (System.Data.Entity.Infrastructure)
Content Source: EF/xml/System.Data.Entity.Infrastructure/DbEntityEntry.xml
Product: entity-framework
Technology: entity-framework-6
GitHub Login: @dotnet-bot
Microsoft Alias: divega

Thank you for requesting a change to the EF6 documentation. We are prioritizing improvements to the EF Core documentation and at this time we are not making changes to the EF6 documentation.
However, we will consider well-written community pull requests to improve the EF6 documentation. The documentation source is located in the EntityFramework.Docs repository on GitHub. To submit a pull request:

Find the file to update and click on it to open

Click on the edit button (✏) to edit in your web browser

When done, add a title and description, then use the "Create a new branch and start a pull request." option.

(Note that you can also clone the docs repo and do a GitHub PR in the normal way.)


Add page's extensions support for API

I've tried to use this library in my project, but in the end, I was forced to write my own serializer because in current implementation we do not support page's extensions. IMHO there should be some option to include extensions data in API

@darkowic thanks for the report, any option that you could help out here by adding the functionality to the package?

I will think about it


undervolt: clarify that the service is unofficial

Motivation for this change
https://github.com/NixOS/nixpkgs/pull/90144#discussion_r446517062
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Thanks!


GetAuth method does not handle multiple Www-Authenticate headers

GetAuthType method in https://github.com/github/git-lfs/blob/master/httputil/request.go#L174 only takes into first WWW-Authenticate header into account. If server sends the following headers:
WWW-Authenticate: Bearer
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

the code returns "basic", which is definitely not correct in this case.
func GetAuthType(res *http.Response) string {
	auth := res.Header.Get("Www-Authenticate")
	if len(auth) < 1 {
		auth = res.Header.Get("Lfs-Authenticate")
	}
	if strings.HasPrefix(strings.ToLower(auth), "ntlm") {
		return "ntlm"
	}
	return "basic"
}

This code will fix the issue:
func GetAuthType(res *http.Response) string {

       authHeaders := res.Header["Www-Authenticate"]

       for i := range authHeaders {
              auth := authHeaders[i]
              if strings.HasPrefix(strings.ToLower(auth), "ntlm") {
                     return "ntlm"
              }
       }

       auth := res.Header.Get("Lfs-Authenticate")

       if strings.HasPrefix(strings.ToLower(auth), "ntlm") {
              return "ntlm"
       }
       return "basic"
}

That's a good idea. I would just extract out a small helper function like:
// getAuthTypeFromHeader("Www-Authenticate")
// getAuthTypeFromHeader("Lfs-Authenticate")
func getAuthTypeFromHeader(key string) {
       authHeaders := res.Header[key]

       for i := range authHeaders {
              auth := authHeaders[i]
              if strings.HasPrefix(strings.ToLower(auth), "ntlm") {
                     return "ntlm"
              }
       }
       return ""
}

Sounds good. I submitted the following PR: https://github.com/github/git-lfs/pull/1378

An aside: Why does LFS prioritize the Www-Authenticate header over an Lfs-Authenticate header? Shouldn't the more specific header be used?

@derrickstolee Good point. I'm wondering if the Lfs-Authenticate header be the more specific one in this case.

It really does not matter in which order we process headers, because we will keep looking until we find a header that supports NTLM.

I was thinking that hard-coding NTLM may not be the right solution if the server can specify the authentication method for LFS separate from the other WWW headers. Perhaps the server is using HTTPS and prefers using basic authentication for LFS.
While there are only two authentication options, it is probably fine to leave it as-is.


Only run validation if input data is actually provided

Describe your changes
Fixes https://credo-ai.atlassian.net/jira/software/c/projects/DSP/boards/29?modal=detail&selectedIssue=DSP-395
Issue ticket number and link
Known outstanding issues that are not fully accounted for
Checklist before requesting a review

[x] I have performed a self-review of my code
[ ] I have built basic tests for new functionality (particularly new evaluators)
[ ] If new libraries have been added, I have checked that readthedocs API documentation is constructed correctly
[ ] Will this be part of a major product update? If yes, please write one phrase about this update.

Extra-mile Checklist

[ ] I have thought expansively about edge cases and written tests for them

We aren't using y_true for anything except to compare against the outputs. It might make sense to move the check for data.X but then we'd be separating them and that feels like an overcomplication.


Migrate WebHooks sender package to ASP.NET Core

Hi,
I've done initial work to migrate sender package to ASP.NET Core. I have been battle-testing this for several months in my work project and it seems to work pretty nice, but I have noticed one serious drawback in the current design. It is the decision to send webhook payload data as two lists: one containing keys and one containing values. It really drives me crazy when I have to reintegrate the payload on the client. Why don't we just post JSON serialized data? I would get rid of NotificationDictionary entirely and let a user send any data he/she wants.
Please tell if my work will be any use for this project, or you guys want to redesign this functionality from scratch as you did with receivers part.
For some reason when I added the files to WebHooks solution and cannot make InternalsVisibleTo work. As a result, the test project doesn't compile hence it uses some internal from Sender Package.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Havret sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Yes, definitely Notification Dictionary should be deleted.

@dougbu Could you take a look at it?

@Havret thank-you very much for the effort you've put into this proposal. On our side, reviewing this PR and investigating alternative designs would require a significant investment. We are not planning to make that investment at this time.
Please feel free to make this work available in another fashion.


Release 3.2.0

Updating repo for release 3.2.0

Codecov Report

Merging #148 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #148   +/-   ##
=======================================
  Coverage   85.63%   85.63%
=======================================
  Files          18       18
  Lines         870      870
=======================================
  Hits          745      745
  Misses        125      125

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 c71a3b5...def744c. Read the comment docs.


New angular templates (part 1)

Template work still in progress. This is a first "beta" state of my work for further testing.
Please review and merge!
Users app:

Show permissions in group form (Fixed #1500)
Added experimental csv import for users.

Agenda app:

Agenda sort view.
Added angular-xeditable for agenda list columns.

General:

Remove old template and js files. Remove old views.

Nice. I did not check JS and HTML. This we can refactor later.

all done. ready for last review.
Note: There are a lot of tests which failed after removing the unused django views. What should we do with these tests now? Removing all failed tests?

Travis fails not because of old tests I think? @emanuelschuetze please check.

@normanjaeckel Now travis failed with the old(!) tests.

Added more commits for adding angular template for motions/categroy/tags/medieafiles.

Skip old tests to fix travis. Ready for review.

motions/urls.py: renamed url_patterns
motions/views.py: all unused views removed.
assignments/urls.py: renamed url_patterns
mediefiles/urls.py ../views.py: this pdf views will be changed after we find a solution to update the file presentation widget. The other views are removed.

@ostcar all done

Rebased on master. Ready for review.
Still open: use new item tree, use new assignment candidate functionality

Ok.

Fixed agenda sort view and item view by using new item tree via rest api.
@ostcar ready for last review!

Looks really good!
I found some strange behaviour in the agenda app

In the list-view, I can not click on the title of an item to get to the detail-view (this is the only way for normal users to see the item)
The pdf-link in the list-view does not work when not logged in
The filter in the list view seems not to work.
In the change sort order view, there is not button to save the changed tree ( but it seems the tree is saved automatically maybe there only need to be a text to explain this)
I can not see in the list view, when an item is a child-item. Maybe there should be more spaces before the title
I am confused about the '%' symbol in duration. You probably mean that no time is set. I don't get this from the sign
There should be an information that the duration is in minutes
The delete button does not work
In the create view it is not clear which fields are required
In the create formular, if you leave any field blank, no item is created, but you are redirected to the overview.

@ostcar I fixed a lot of your reported issues. Some points are opened as new issues. All done. Ready for next review!
Note: In my last commit is still a TODO because I get a strange error if ng-fab-forms is includes (which does not happens with a clean ng-fab-forms demo; so maybe a OpenSides/angular problem?) Any idea?

I just added some more template improvements (ui-bootstrap and ngbootbox). Please let me know when I can rebase all commits.

Looks good. I would say that we merge all this and fix any problem later.
So please rebase

Rebased.

Rebased again after merging #1514 .

@normanjaeckel Do you want to look at this? If not, please merge

@normanjaeckel ping


Textile support?

Hi,
do you plan to add Textile support?
http://en.wikipedia.org/wiki/Textile_(markup_language)
It's a "standard" in the ruby world. Eg. http://www.redmine.org
Greez Jens

Closing as too old.


Weird server issues when specs run

Whenever specs run/fail I get this:

/Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/dante-0.1.5/lib/dante/runner.rb:159:in `parse_options': invalid option: -f (OptionParser::InvalidOption)
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/dante-0.1.5/lib/dante/runner.rb:50:in `execute'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/stripe-ruby-mock-<IP_ADDRESS>/lib/stripe_mock/api/server.rb:21:in `kill_server'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/stripe-ruby-mock-<IP_ADDRESS>/lib/stripe_mock/api/server.rb:16:in `block in spawn_server'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:103:in `fork'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:103:in `command'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:80:in `block (3 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:80:in `fork'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:80:in `block (2 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `each'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `block in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `loop'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (3 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `fork'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (2 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `each'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `block in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `loop'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (3 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `fork'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (2 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `each'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `block in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `loop'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (3 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `fork'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (2 levels) in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `each'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:73:in `block in go'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `loop'
    from /Users/Bob/.rvm/gems/ruby-1.9.3-p448@someapp/gems/zeus-0.13.3/lib/zeus.rb:62:in `go'
    from -e:1:in `<main>'

The weird thing is if I don't run Zeus it doesn't even run at all. Very annoying.
Setup: guard-rspec/zeus

I'm having this same issue. It has nothing to do with Spring / Zeus for me. If I run the whole test suite I get the same error as ecl1pse. But a strange thing happens when I run just the test in questing (that is using StripeMock's server). It seems I get a PostGres error plus it's not even running the tests. Spent the morning trying to get this to work but no luck.
Here's my logs in case it helps solve this:
$ rspec spec/features/client_subscribes_spec.rb
Daemon has started successfully

Finished in 0.05252 seconds (files took 5.9 seconds to load)
0 examples, 0 failures
Killing server at ./stripe-mock-server.pid
No stripe-mock-server processes are running
/Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/database_statements.rb:147:in `async_exec': PG::ConnectionBad: PQsocket() can't get socket descriptor:             SELECT tablename (ActiveRecord::StatementInvalid)
            FROM pg_tables
            WHERE schemaname = ANY (current_schemas(false))
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/database_statements.rb:147:in `block in query'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/abstract_adapter.rb:466:in `block in log'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activesupport-4.2.0/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/abstract_adapter.rb:460:in `log'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/database_statements.rb:146:in `query'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/schema_statements.rb:91:in `tables'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/referential_integrity.rb:23:in `rescue in ensure in disable_referential_integrity'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/referential_integrity.rb:20:in `ensure in disable_referential_integrity'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql/referential_integrity.rb:20:in `disable_referential_integrity'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/database_cleaner-1.3.0/lib/database_cleaner/active_record/truncation.rb:204:in `clean'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/database_cleaner-1.3.0/lib/database_cleaner/base.rb:40:in `clean_with'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/database_cleaner-1.3.0/lib/database_cleaner/configuration.rb:91:in `block in clean_with'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/database_cleaner-1.3.0/lib/database_cleaner/configuration.rb:91:in `each'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/database_cleaner-1.3.0/lib/database_cleaner/configuration.rb:91:in `clean_with'
	from /Users/amarkle/Dropbox/Sites/houndapp/spec/support/database_cleaner.rb:3:in `block (2 levels) in <top (required)>'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:322:in `instance_exec'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:322:in `instance_exec'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:350:in `run'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:427:in `block in run'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:427:in `each'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:427:in `run'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:500:in `run'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:110:in `block in run_specs'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/reporter.rb:53:in `report'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:107:in `run_specs'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:85:in `run'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:69:in `run'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:37:in `invoke'
	from /Users/amarkle/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/rspec-core-3.1.7/exe/rspec:4:in `<top (required)>'
	from /Users/amarkle/.rbenv/versions/2.2.0/bin/rspec:23:in `load'
	from /Users/amarkle/.rbenv/versions/2.2.0/bin/rspec:23:in `<main>'

And here's my test:
require 'rails_helper'
require 'stripe_mock'

StripeMock.spawn_server

feature "Customer subscribes to her company's plan" do

  background do
    @plan = create(:plan)
  end

  scenario "successfully and creates client in database", js: true do
    StripeMock.start_client

    visit<EMAIL_ADDRESS>
    expect(page).to have_css 'h1', text<EMAIL_ADDRESS>    expect(page).to have_content "$10.00"

    fill_in "name", with: "Toshiro Mifune"
    fill_in "email", with<EMAIL_ADDRESS>    fill_in "Card number", with: "4242424242424242"
    fill_in "cc-exp", with: "03 2020"
    fill_in 'CVC', with: '333'

    click_button 'Subscribe'
    expect(page).to have_content "THANKS"

    StripeMock.stop_client
  end
end

I get the same error. I don't use zeus or spring, but I use guard. My test suite runs fine, if I just call "rspec spec", but I get the above error from guard.
Using stripe-ruby-mock 2.0.1, rails 4.2, stripe 1.17.3., dante 0.2.0

This guard issue could be connected to the problem…

I use spring and ran into the same problem as described by  ecl1pse  on Jul 27, 2013.
My solution was to move the Gemfile.lock to the trash and run $ bundle
I used that to sort it all out.

@ecl1pse @andrewmarkle  you still have this problem?

I am having this issue @alexmamonchik

workaround: https://github.com/stripe-ruby-mock/stripe-ruby-mock/issues/219#issuecomment-114231782

Is this fixed or we just use the workaround and that's it??


Add JmxOpenMetricsModule

Description
Add JmxOpenMetricsModule.

Release notes
(x) Release notes are required, with the following suggested text:
* Add openmetrics endpoint at `/metrics`

Can you chime in here @mattstep ? Do we want to be able to enable/disable it or is this all built into the module and ready to go and we just got to update the docs?

OpenMetrics is different from OpenTelemetry.
Airlift module for OpenTelemetry is io.airlift:tracing.

OpenMetrics is different from OpenTelemetry. Airlift module for OpenTelemetry is io.airlift:tracing.

Ooops.


Guild Alliance, Hostility, Suspend Hostility nor working

Describe the bug
Can't add a guild to alliance or to hostility
To Reproduce
Press D -> click on Hostility or Alliance -> click on another Guild Master from a different guild -> nothing happens
Expected behavior
Player should receive an offer of the alliance request
Desktop (please complete the following information):

OS: win 11

Guild Alliances are not implemented yet.


Multiple numa support

More than one NUMA should be supported.
Especially in server systems, there are 2 NUMA. But WSL only uses 1 of them. And the maximum 64 processor limit should be increased.
Especially there are servers that only run WSL. And all resources are used for WSL. But since there is only one NUMA support, half of the CPU resources are wasted. Having 2 NUMA support would be very good for performance. For those who want to use single NUMA, settings can be made from the .wslconfig file.

WslLogs-2024-09-17_23-35-51.zip

WslLogs-2024-09-17_23-54-31.zip

/feature
WslLogs-2024-09-18_00-00-27.zip

Hi @muratyurdakul75 I see that you want more than 64 threads in Pi Node. I have 2 NUMA 16/32, 64T in total, so the WSL2 fix was not needed yet. My another server with more than 64T is on the way, but I already work on resolving this for >64T.
Try this and let me know your result https://github.com/xieyubo/WSL2

WslLogs-2024-09-18_18-05-19.zip

/emailed-logs

MERHABA@muratyurdakul75Pi Node'da 64'ten fazla iş parçacığı istediğinizi görüyorum. Toplamda 2 NUMA 16/32, 64T'im var, bu yüzden WSL2 düzeltmesine henüz gerek kalmadı. 64T'den fazla iş parçacığına sahip başka bir sunucum yolda, ancak >64T için bunu çözmek için şimdiden çalışıyorum. Bunu deneyin ve sonucunuzu bana bildirin https://github.com/xieyubo/WSL2

This issue has been resolved. Thank you very much for your efforts.

Hi @muratyurdakul75 , can you share how exactly was it resolved ? I'm running my app's containers in 2 NUMA config but WSL2 can access only half of my resources (One NUMA). Thanks

Hi @muratyurdakul75 , can you share how exactly was it resolved ? I'm running my app's containers in 2 NUMA config but WSL2 can access only half of my resources (One NUMA). Thanks

All you need to do is install WSL 2.4.5. This version uses all processors.


Add support for Image.decode

It will be good to get support for image.decode which is a useful feature (https://medium.com/dailyjs/image-loading-with-image-decode-b03652e7d2d2)
Also, refer
https://www.chromestatus.com/feature/5637156160667648

Duplicate of #3902?

Yup!


Reader for scienta .ibw (Igor binary wave) data

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

34 of 146 (23.29%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.8%) to 65.59%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pynxtools_xps/value_mappers.py
1
8
12.5%

pynxtools_xps/scienta/scienta_igor.py
31
136
22.79%

Totals

Change from base Build<PHONE_NUMBER>:
-1.8%

Covered Lines:
2314

Relevant Lines:
3528

💛  - Coveralls


Making card component

That's How to use the card
<BountyCard          imageSource="/dummyImg.png"          bountyTitle="Bounty title"         bountyPrize="$10,000,000"         />

after reversing

It seems that some parts of the BountyCard overflow at certain widths. Also, the image is squeezing. I believe a gap between chips would also be needed to make it mirror the Figma as closely as possible.

It seems that some parts of the BountyCard overflow at certain widths. Also, the image is squeezing. I believe a gap between chips would also be needed to make it mirror the Figma as closely as possible.

It seems that some parts of the BountyCard overflow at certain widths. Also, the image is squeezing. I believe a gap between chips would also be needed to make it mirror the Figma as closely as possible.

I didn't work on making it responsive for mobile.


Add CSVRecord.isSet(int) method

Added the isSet(int) method to CSVRecord for checking whether a column with a given index is set. Also removed unnecessary unboxing of an Integer variable in the CSVRecord#isSet(String) method.

Coverage increased (+0.007%) to 92.928% when pulling 909b19e807afc363983b6a9c419f566ca4c0f54b on 0x100:isset_i into 129641ead46c8faefdb18903e283f7c4f55a000d on apache:master.


Update progress bar component to accept custom color indicator

Purpose: Allow consumers to change the indicator of the progress bar to any custom color they want, in addition to our presets.

AC

Allow consumer to use a string like "#B12FAD" to set the color of the indicator.
Make sure the track can still not be changed.
How can we handle allowing a different color set when Inversed?

Make a note in the docs site that, when using custom colors, they must be checked for color contrast for a11y.

Create an example that swaps between using chartColorsInverse and chartColors depending on whether the ProgressBar is using inverse.

QA complete - Update to progress bar and documentation looks great.

Looks good here!


"Security Group" vs Azure Active Directory Security Group and Active Directory Security Group

Instead of "Security Group", I think it would be helpful to list the specific types of security groups like below. This is how most people refer to these types of groups. The generic term "security group" is not specific enough and leaves questions in the user's mind about what types of security groups can be used.
Azure Active Directory Security Group
Active Directory Security Group

You can use the following groups to set up row level security.
Distribution Group
Mail-enabled Group
Security Group

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: d5505062-94f3-e15d-a52f-ce1ac7f8cb69
Version Independent ID: 34076b73-0ded-2111-ed44-2a31e07deb53
Content: Row-level security (RLS) with Power BI - Power BI
Content Source: powerbi-docs/enterprise/service-admin-rls.md
Service: powerbi
Sub-service: powerbi-admin
GitHub Login: @paulinbar
Microsoft Alias: painbar

Hi @djurecic0, thanks for the input. I think you are right to say that this needs to be more specific. Let me see if I can get that information from the developers.

Thanks for your comment, @djurecic0. This issue has been assigned to the doc author for review.

Thanks for the suggestion, @djurecic0, I updated the doc for clarity.


nixos/espanso: add required capabilities for wayland

On Wayland, Espanso depends on cap_dac_override+p for the EVDEV
backend. Specifically, this capability is required by the worker
thread, which is forked from the main espanso process when run by the
usual means (espanso start or espanso daemon).
Espanso (responsibly) drops capabilities as soon as possible, prior
to forking the worker process. Unfortunately, security.wrappers sets
the capabilities in such a way that the forked process does not pick
up these capabilities (due to /proc/self/exe pointing to the original
espanso binary, which does not have these capabilities).
By running worker directly from the capability-enabled wrapper,
the worker thread is able to run without issue, and Espanso runs as
expected on wayland.

https://github.com/NixOS/nixpkgs/issues/249364

https://github.com/NixOS/nixpkgs/pull/328890

https://espanso.org/docs/install/linux

fixes https://github.com/NixOS/nixpkgs/issues/249364

Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

@pitkling added some fair criticisms of this approach here

Continuing the discussion from #249364 (especially this comment) here, to avoid spamming that issue unnecessarily.
First of all, thanks for digging further into this approach! It's definitely worth pursuing and might be a good alternative to PR #328890.
From your issue description, I get it that the CAP_DAC_OVERRIDE requirement of espanso is a wayland-only thing? Is that documented somewhere? Just asking, since in that case I'll update my draft PR #328890 accordingly.
(quotes from #249364, this comment)

[…]

This means that the espanso team could remove/change/substitute/rename/… that subcommand any time

True, but the nix input won't change until we change it. I've been trying to help the espanso team here and there; there's been talk about a big-ish refactor of the GUI to remove the wx dependency, but I haven't heard of any immediate plans for a major refactoring of the backend. (EDIT: espanso roadmap)

True enough, there won't be problems until we update the derivation. I'm mostly worried about upstream changes in the backend that we are unaware of and that do not cause build problems. E.g., the espanso team might keep the worker subcommand but add additional features relying on some monitor process managing the worker. We would not spot those problems on a derivation update but they could cause problems much later that might be difficult to figure out.

automatically restarting the worker if the configuration changed

Good point, I need to double check this. Requiring manual reload to pick up config changes would be a bit of a bummer (since they've already done the work to make this smoother).
The systemd unit should be automatically restarting on failure, which might obviate the need for some of their checks.

Good point, that definitely helps. Still, there must be more to it, right? Otherwise, why would the espanso team not make use of this themselves in their reference systemd service?

Even if it works now, it might break future features if some internals change.

That's of course possible, though I'm not sure what approach could prevent upstream changes from breaking the always-unconventional nix way. […]

That's true, it's not possible to avoid such issues. I'm just worried that this approach is more prone to these problems since (a) it relies on the seemingly not-well documented workings of an internal subcommand and (b) we might not even spot problems until much later when updating the derivation (as I mentioned above).
It seems to me that the approach via the wrapper library from #328890 (which definitely has its own problems!) has the benefit on not relying on internals (at least not much; I don't think it's likely that the espanso team changes process forking in a way that is not captures by the wrapper library) and (b) if there are upstream changes breaking that approach, we should realize this very quickly (not necessarily at build time, but the process will most likely not work at all, as it is currently the case at least on wayland).

Btw., I will sometime soon (currently somewhat busy) create a issue for discussing whether such problems can be handled directly by security.wrappers, as you suggested here. But I think we should implement a fix for #249364 (whether this PR or https://github.com/NixOS/nixpkgs/pull/328890) anyways, since I think even if security.wrappers can handle this, it will take some time to implement such a change.

From your issue description, I get it that the CAP_DAC_OVERRIDE requirement of espanso is a wayland-only thing? Is that documented somewhere? Just asking, since in that case I'll update my draft PR https://github.com/NixOS/nixpkgs/pull/328890 accordingly.

I think so -- I linked to the linux installation instructions above, capabilities are only mentioned in the wayland section.

I'm mostly worried about upstream changes in the backend that we are unaware of and that do not cause build problems.

Certainly possible, but I think you might be over-worried here. I am involved in espanso development and intend to become more involved over time. Similarly, I'm listed as a maintainer of the espanso package and module; with any luck I'll be able to help watch for issues here going forward.
Can you elaborate on a worst-case scenario in your mind? I want to make sure we're speaking the same language; in my mind, you're suggesting that:

an upstream minor or patch-level change could reasonably change the behavior of espanso worker, since it's not part of their public API
if this were the case, we might update the src and do some basic testing* and find that espanso still seems to work and update the derivation
at some point, someone would discover an edge case in which something wasn't working and file a bug report
in that case, we would likely have to revert the PR updating src -- fairly trivial to do in nixos -- and then consider other options (perhaps security.wrappers will have an option to intercept /proc/self/exe calls by then).

Is that more-or-less the risks that concern you? As a hobbyist self-taught programmer, sometimes I am completely blind to the concerns that professionals assume I am taking into account.
* perhaps we could consider adding an espanso nixos test for espanso?

Still, there must be more to it, right? Otherwise, why would the espanso team not make use of this themselves in their reference systemd service?

I might be misunderstanding -- their reference service does leverage systemd's automatic service restarts: Restart=on-failure, which is what I was referring to.
Also -- for context -- espanso's creator and primary dev @federico-terzi has done an amazing job but has openly noted that he is not going to be able to focus on espanso for the time being (https://github.com/espanso/espanso/issues/1742); @AucaCoyan and others have stepped up, but issues like https://github.com/espanso/espanso/issues/1953, https://github.com/espanso/espanso/pull/1963, and many others show that there is still a lot of work to be done to even get development back on track. I only bring this up to point out that they are an extremely welcoming community that is hungry for additional contributors; I still think that an upstream patch should be considered if we can come up with a strategy that would ameliorate nix issues and be a win (or net even) for the espanso team. They've showed a lot of flexibility working with 3rd party package management in the past (https://github.com/espanso/espanso/issues/615) and are generally very nice people.

From your issue description, I get it that the CAP_DAC_OVERRIDE requirement of espanso is a wayland-only thing? Is that documented somewhere? Just asking, since in that case I'll update my draft PR #328890 accordingly.

I think so -- I linked to the linux installation instructions above, capabilities are only mentioned in the wayland section.

Ahh, you're right. I'll update my PR draft accordingly.

I'm mostly worried about upstream changes in the backend that we are unaware of and that do not cause build problems.

[..] Can you elaborate on a worst-case scenario in your mind? I want to make sure we're speaking the same language; in my mind, you're suggesting that:

an upstream minor or patch-level change could reasonably change the behavior of espanso worker, since it's not part of their public API
if this were the case, we might update the src and do some basic testing* and find that espanso still seems to work and update the derivation
at some point, someone would discover an edge case in which something wasn't working and file a bug report
in that case, we would likely have to revert the PR updating src -- fairly trivial to do in nixos -- and then consider other options (perhaps security.wrappers will have an option to intercept /proc/self/exe calls by then).

Is that more-or-less the risks that concern you? […]

Yes, that's basically it. In general I think it's more robust to stick to openly documented interfaces, to keep maintenance low. That's also why I still think the approach from #328890 requires probably lower maintenance of the NixOS module code (major concern for #328890) than the approach here. But given that you're involved in espanso's development definitely weakens those arguments.

Still, there must be more to it, right? Otherwise, why would the espanso team not make use of this themselves in their reference systemd service?

I might be misunderstanding -- their reference service does leverage systemd's automatic service restarts: Restart=on-failure, which is what I was referring to. […]

Yes, but they're running espanso launcher, not espanso worker. I just wanted to point out that this is another indicator that the launcher does more than simply restarting espanso on failures.

Ahh, you're right. I'll update my PR draft accordingly.

Trying to test to confirm (on an Arch host running i3 over VNC, with espanso built from source), espanso runs and seems to try to expand without any additional capabilities. Unfortunately it succeeds at deleting the trigger text but the replacement text doesn't appear; I suspect this is an issue with the clipboard and VNC. It is definitely different than the "crash at launch" that I get on Wayland when trying to run without capabilities.
Also, regarding your PR -- IMO users installing espanso with package = pkgs.espanso-wayland should -- with documentation -- be opting into the wrapper by default. If espanso cannot work on wayland without these capabilities, and we're not going to provide a service that runs as root by default, I think that choice should be enough for the rest to configure itself to be usable. What are your thoughts on simplifying some of your PR to make the module "just work" based on the user's choice of package?

That's also why I still think the approach from https://github.com/NixOS/nixpkgs/pull/328890 requires probably lower maintenance of the NixOS module code (major concern for https://github.com/NixOS/nixpkgs/pull/328890) than the approach here.

Did you mean to put the same PR for both of those links? Assuming so -- that's interesting, I still worry that the complexity of that approach would make it far more difficult (for me! though perhaps not for you or hypothetical maintainers) to debug / maintain when something eventually goes wrong. Even if it isn't the ultimate cause of a bug, when a bug arises this code should be considered as part of the machinery that is under examination -- and I don't think I could do that well. I am reasonably comfortable with nix and rust, which is why I thought I could help on the respective teams, but I never learned the C family!
That said, your explanatory comments in the code are wonderful and give me a fighting chance at understanding the approach you've taken.

Yes, but they're running espanso launcher, not espanso worker. I just wanted to point out that this is another indicator that the launcher does more than simply restarting espanso on failures.

Correct -- and this is part of my point. Both NixOS and Home-Manager modules are currently using espanso daemon -- which is also undocumented but seems to have been working well so far. The documented / blessed path for Linux is to imperatively run espanso service register and then espanso start thereafter -- it doesn't mention launcher AFAICT. It even does runtime checks to make sure the systemd file points to the expected binary and expects to find it at /usr/local/bin/espanso. For MacOS, the only documented install processes are downloading the .app to Applications or homebrew, and espanso installs its own plist to manage the service, which also uses espanso launcher (not espanso start).
So whichever way we go, just by using nix, I think we're already pretty far off the well documented path.
It seems that @KenMacD has been using the espanso worker approach for months with generally satisfactory results while the rest of us wayland suckers languish :)

[…] Also, regarding your PR -- IMO users installing espanso with package = pkgs.espanso-wayland should -- with documentation -- be opting into the wrapper by default. If espanso cannot work on wayland without these capabilities, and we're not going to provide a service that runs as root by default, I think that choice should be enough for the rest to configure itself to be usable. What are your thoughts on simplifying some of your PR to make the module "just work" based on the user's choice of package?

I just did update #328890. It is now its own small module programs.espanso.capdacoverride that, if enabled (right now the default) just makes sure that everything works out of the box. To do so it creates the security wrapper and overlays pkgs.espanso-wayland with the capability-enabled version. I'm not sure whether automatic overlays by modules are a good idea, but at least makes sure that pkgs.espanso-wayland just works, no matter where it is used.
(BTW: I also just tested myself that running espanso worker directly does not pick up configuration changes, while that works flawlessly with #328890).

That's also why I still think the approach from #328890 requires probably lower maintenance of the NixOS module code (major concern for #328890) than the approach here.

Did you mean to put the same PR for both of those links? Assuming so -- that's interesting, I still worry that the complexity of that approach would make it far more difficult (for me! though perhaps not for you or hypothetical maintainers) to debug / maintain when something eventually goes wrong. Even if it isn't the ultimate cause of a bug, when a bug arises this code should be considered as part of the machinery that is under examination -- and I don't think I could do that well. I am reasonably comfortable with nix and rust, which is why I thought I could help on the respective teams, but I never learned the C family!
That said, your explanatory comments in the code are wonderful and give me a fighting chance at understanding the approach you've taken.

I absolutely get your reservation, and if you don't feel those changes are worth the hassle, that's fine :). If it helps, I'd be willing to maintain that part if wanted. BUT I should say that I have never written a single line of Rust code, so not sure how helpful I can be with issues related to Espanso internals.
But yes, I think it's lower maintenance (I meant PR #328890 in both cases). I think it is pretty orthogonal to any changes to the espanso package and module. I cannot see many upstream changes that would cause hiccups with the wrapper; the most likely breaking change would be that Espanso no longer uses the libc-based fork, but then the wrapper just behaves as the original. Also, one can easily disable the wrapper completely via programs.espanso.capdacoverride.enable = false; with this, there is actually no difference at all to the status quo (so one can easily check whether the wrapper is causing problems or not).
Note that the way #328890 is implemented now does neither touch the Espanso package definition nor the Espanso module code directly. The way I wrap the Espanso package in nixos/modules/services/desktops/espanso-capdacoverride/espanso-capdacoverride.nix is quite orthogonal to the original package definition. And by overlaying pkgs.espanso-wayland (again, not sure this is a good approach, but then we could make the overlay opt-in) it requires no changes to the espanso NixOS module at all and immediately works for the corresponding home-manager module (or any other place using pkgs.espanso-wayland) without any changes.

Yes, but they're running espanso launcher, not espanso worker. I just wanted to point out that this is another indicator that the launcher does more than simply restarting espanso on failures.

Correct -- and this is part of my point. Both NixOS and Home-Manager modules are currently using espanso daemon -- which is also undocumented but seems to have been working well so far. […]
So whichever way we go, just by using nix, I think we're already pretty far off the well documented path. […]

Ah, I wasn't ware that daemon and launcher are also not documented. Very good point! That definitely eases my concerns with respect to the stability of worker. Still, we would have at least to figure out what problems may occur (like not reloading the configuration) without the monitoring code from launcher and whether one can fix them somehow (or live with them).

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/espanso-daemon-problem/35309/27

Closing in favor of https://github.com/NixOS/nixpkgs/pull/328890


Enhancements for [ExtendObjectType]

Problem and proposed solution
Currently ExtendObjectType is great for extending one type at a time, but we can make this way cooler for cross-cutting scenarios when you want to extend multiple types with single field resolver implementation. Originally raised on #1298 ages ago but I forgot to create a new issue!
It doesn't look like [ExtendObjectType] has an equivalent for [GraphQLResolverOf(types/typeNames)] (at least on 10.5) as the attribute is restricted to only one usage on a class. Would be cool if we could do this:
// Interface enforcing the FK
public interface IHasBooking
{
    [GraphQLIgnore]
    int BookingId { get; }
}

// Mutations payloads that return a booking field
public class CreateBookingPayload : IHasBooking { ... }
public class EditBookingPayload : IHasBooking { ... }

// A normal type that has a relation to a booking
public class BookingOfferPayload : IHasBooking { ... }

//[ExtendObjectType(Name = nameof(CreateBookingPayload))]
//[ExtendObjectType(Name = nameof(EditBookingPayload))] // second one doesn't work as not allowed by compiler
[ExtendObjectType(typeof(IHasBooking))]
public class HasBookingResolvers
{
    public Task<Booking> GetBooking([Parent] IHasBooking x)
        => bookingDataLoader.LoadAsync(x.BookingId);
}

For the extending of the interface, perhaps more pure for those with C# lang version to support it, would be even to allow default method implementations on the interface to be interpreted as resolver methods, though this may need an opt-in flag as it could be breaking.
// Interface enforcing the FK and also providing the resolver method / field
[ExtendImplementingTypes] // opt-in all methods
public interface IHasBooking
{
    [GraphQLIgnore]
    int BookingId { get; }

    [GraphQLField] // opt-in just this method
    [GraphQLIgnore] // opt-out just this method (for when class has ExtendImplementingTypes)
    public Task<Booking> GetBooking([Parent] IHasBooking x)
        => bookingDataLoader.LoadAsync(x.BookingId);
}

Another scenario as raised in #2136 is via a base class, which would also be good to support but base classing isn't always as easy.
So it'd be cool if we could support a few ways of doing this. My wishlist in order of most wanted first would be:

[ ] Extension by interface only with attributes (with resolver implemented as default member)
[ ] Extension by [ExtendObjectType(typeof(IHasBooking))] with interface type (supports cases when interface can't cross-cut)
[ ] [ExtendObjectType] to allow multi usage (supports cases when interface/base can't cross-cut)
[ ] Extension by [ExtendObjectType] with base class (dupes #2136)

In #2136, there's mention of a bool flag to turn on/off propagation, we should consider that further here too.
We may also need to think about the fluent code-first style, e.g. InterfaceType.
Finally:

[ ] [GraphQLIgnore] on the interface field should ignore bookingId from becoming exposed in the schema on concrete types (currently it doesn't, which could be logged elsewhere).

Describe alternatives you've considered
The only alternative right now is to do a HasBookingResolversBase with the resolver method and a class per type you want to extend which is painful.
Additional context
n/a

One issue to consider too is when different authorization is required for different implementors.

Interesting interface default implementation playground... https://dotnetfiddle.net/7eLRMP
You can access the default, but if you call it from the overrided implementation it calls itself infinitely, makes sense.
So you need to abstract the implementation out to a static method.
MS docs.

Perhaps putting a resolver method on an interface is mixing concerns a little too much. Mixing in HotChocolate/GraphQL stuff into potentially a domain interface. The [ExtendObjectType] is preferable most of the time because you can extend right at the last moment when you're in "graph land".
So I'll  think the extension by C# interface only is maybe less of a priority, but an interesting idea :P

you can use recursive generics to depend on type directly instead of interface

@dzmitry-lahoda can you open a separate issue for this?

We have implemented this a bit differently. We will also add more features to this over time.
Here are some base examples.
Lets say we have the following:
public class Session
{
    public int Id { get; set; }
    [Required]
    [StringLength(200)]
    public string? Title { get; set; }
    [StringLength(4000)]
    public string? Abstract { get; set; }
    public DateTimeOffset? StartTime { get; set; }
    public DateTimeOffset? EndTime { get; set; }
    // Bonus points to those who can figure out why this is written this way
    public TimeSpan Duration =>
        EndTime?.Subtract(StartTime ?? EndTime ?? DateTimeOffset.MinValue) ??
            TimeSpan.Zero;
    public int? TrackId { get; set; }
    public ICollection<SessionSpeaker> SessionSpeakers { get; set; } =
        new List<SessionSpeaker>();
    public ICollection<SessionAttendee> SessionAttendees { get; set; } =
        new List<SessionAttendee>();
    public Track? Track { get; set; }
}

Case 1: we want to replace the field TrackId with the actual Track:
[ExtendObjectType(typeof(Session))]
public class SessionResolvers
{
    [BindProperty(nameof(Session.TrackId))]
    public async Task<Track?> GetTrackAsync([OriginalProperty] int? trackId) => ....
}

Case 2 a: we want to remove a property
[ExtendObjectType(typeof(Session), IgnoreProperties = new[] { nameof(Session.TrackId) })]
public class SessionResolvers
{
}

Case 2 b: we want to remove a property
[ExtendObjectType(typeof(Session))]
public class SessionResolvers
{
    [GraphQLIgnore]
    public Track? Track { get; set; }
}

case 3: we want to add a field to multiple types
[ExtendObjectType(typeof(object))] <--- everything that inherits or implements this type is extended
public class SessionResolvers
{
    public string Info([Parent] object parent) => "hello";
}

case 4: we want to have an extension type that extends depending on the parent argument
[ExtendObjectType(typeof(object))] <--- everything that inherits or implements this type is extended
public class SessionResolvers
{
    public string Info([Parent] Session parent) => "hello"; <---- this is added to all types that inherit, implement or are equal to the parent argument type
}
``


[http-client-python] pylint report differently in Windows and Linux environment

For same code, CI passes  in Linux while fails in Windows.
It may be caused by different python version. In windows, python version is 3.12 while in linux it is 3.8.

We are in dilemma If we add pylint disable to fix for Windows, it will cause useless-suppressions info in Linux; if we do nothing, pylint fails in Windows...


Cannot get expected model size reducing when lauching squeezellm mode

Hi Everybody,
I'm simply following vllm (version 0.3.0) helper to run a squeezellm quantized llama-2 model, using following command
python3 -m vllm.entrypoints.openai.api_server --model squeeze-ai-lab/sq-llama-2-7b-w4-s0 --tensor-parallel-size 1 --max-model-len 1000 --gpu-memory-utilization 0.9 --quantization squeezellm
It runs well but  nvidia-smi show that model is occupying ~15Gb among the 16Gb available in my NVIDIA V100, while i expected model size to be reduced by 4.
Is there something i did wrong? Does my GPU fit with squeezellm quantization requirements? Or maybe my environement has not been built the right way?
Thanks for any help or any link that show successful use of llama-2 with squeezellm
Regards

Hi @ykacer, vLLM pre-allocates the GPU memory for KV cache at the initialization time. In your case, it occupies roughly 90% of your total GPU memory since gpu-memory-utilization is 0.9. You can control this value to limit vLLM's GPU memory usage while higher values enables larger maximum batch size and thus leads to higher throughput.


[Discussion] Removal of Azure Functions version 3.0.15193

Discussion issue for removal of Azure Functions version 3.0.15193

Hello @gzuber
Following the announcement of removal of Azure Functions Runtime 3.0.15193 (https://github.com/Azure/app-service-announcements/issues/324), is it possible to get an ETA on when the removal will take effect for this Function App? Thank you.

Hi @cyc4 - It's hard to give an exact date. There's a different release happening right now so this change won't start until that finishes rolling out. The best estimate I can give is that this change might start rolling out in 3-4 business days, but this is very dependent on how the other release roles out. Is there a concern with removing this version I can help with?

Hello @gzuber
Thank you for your prompt reply.
My customer have to push changes to their app to keep it functioning and their release was initially planned for Tuesday. They are worried about the removal of the version will impact their business.
So if they have gotten the exact date that would be helpful for the release.
Besides, will the runtime change only take effect if the function is restarted? Thank you.


CI error: error CS0103: The name 'SyncedEnforcer' does not exist in the current context

https://github.com/casbin-net/casbin-aspnetcore/actions/runs/3630850164/jobs/6124702645

Actually, there is no SyncedEnforcer class in this project. I have searched the keyword SyncedEnforcer and let my IDE find them in files, and it turned out the keyword SyncedEnforcer only appears three times.
So, I believe this issue may be caused by some copy-paste problems. I will fix it in my next PR.

The reason is dependency package version be deleted.

The reason is dependency package version be deleted.

@sagilio So, how shall we solve this? you could request change in my PR here https://github.com/casbin-net/casbin-aspnetcore/pull/57.

Fixed by https://github.com/casbin-net/casbin-aspnetcore/commit/85ad73cca19ae59ff6fb94e2e1e67510bfbd4975


Back compat story between container runtime & component runtime

Per discussion in https://office.visualstudio.com/OC/_git/office-bohemia/pullrequest/459732?discussionId=10702591, we need to start enforcing some level of compatibility between container runtime and component runtime.
I've put it under "Versioning" project, but I guess we need different versioning projects (as there are different weakly overlapping areas), or some kind of sub-areas for it.

This is already implemented and enforced