Global substitutions vs personalization substitutions

Issue Summary
I'm sending an email using a transactional template, passing in the content as it is a generic template, and sending it to multiple recipients, and I don't want each recipient to see who else it is going to. Each recipient will see a personalized "Hello {{first_name}}" above the content of the message.
Say I call addGlobalSubstitutions on a Mail object, with properties such as title, content and footer. I don't want these to vary between the recipients.
I then add a Personalization for each receipient, and on each one I call addSubstitution with a key of first_name and the value being the person's name.
What is then happening is the global substitutions are being ignored, and the emails are sending but there is no title, content or footer, just the "Hello {name}" part with the person's name.
Is it expected behaviour that by adding substitutions to personalizations, the global substitutions are not used at all? I was hoping that they would individually override, so the first person would get title, content, footer, and first_name (with their name), the next person the same but with their name, etc, etc.
Technical details:

sendgrid-php Version: 7.2.1
PHP Version: 7.2.8

I am experiencing something similar but with custom_args.
I am intending to add a global custom_args object, but the args are only added to the first Personalization. I have an example test that shows this, and I'm curious if it's intentional or not.
    public function testCustomArgsInNewMessage()
    {
        $email = new \SendGrid\Mail\Mail();

        $customArgs = [
            "marketing2" => "true",
            "transactional2" => "false",
            "category" => "name"
        ];
        $email->addCustomArgs($customArgs);
        $json = json_encode($email->jsonSerialize());

        $this->assertEquals(count($email->getCustomArgs()), 3);
        $this->assertEquals(count($email->getCustomArgs(0)), 0); // why is this 3?
    }

@erbaker Have you tried using addGlobalCustomArgs instead?

@gavrichards yeah that did it _
This does seem not quite as intuitive, but I think I understand why it was done that way. Thanks!!

Hi @gavrichards,
Generally, I recommend folks to follow our transactional template example.
However, if you can either provide the code or the request body, I can try to reproduce. Thanks!
With Best Regards,
Elmer

@thinkingserious but the example doesn't make use of global substitutions which is the key here.
I've cleaned up a version of my code for you to try. Thanks!
$fromEmail =<EMAIL_ADDRESS>$fromName = 'Example McExampleFace';
$subject = 'Subject';
$text = 'Text email';
$templateId = 'abc123';
$globalSubstitutions = [
    'subject' => $subject,
    'content' => nl2br($text),
];
$to = [
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>];
$substitutions = [
    'first_name' => [
        'Gav',
        'Sarah',
        'Dave',
    ],
];

$sendgrid = new Sendgrid($apiKey);

$mail = new SendGrid\Mail\Mail(
    new SendGrid\Mail\From($fromEmail, $fromName),
    null,
    new SendGrid\Mail\Subject($subject)
);

$mail
    ->addContent('text/plain', $text);

$mail
    ->setTemplateId($templateId);

$mail
    ->addGlobalSubstitutions($globalSubstitutions);

$i = 0;
foreach($to as $address)
{
    $personalization = new SendGrid\Mail\Personalization();
    $personalization
        ->addTo(new SendGrid\Mail\To($address));

    foreach($substitutions as $key => $vals) {
        $personalization
            ->addSubstitution($key, $vals[$i]);
    }

    $mail
        ->addPersonalization($personalization);

    $i++;
}

$sendgrid
    ->send($mail);

Hello @gavrichards,
I think I see the issue, can you try building your mail objects without passing parameters to the constructor like so?
When you use the constructor with arguments we create an initial Personalization object behind the scenes at index 0.
Also, looking at the request body may also offer some clues.
Please take a look and let me know the results. Thanks!
With Best Regards,
Elmer

@thinkingserious thanks - I thought the arguments in the constructor were required, has that changed at some point, or was I incorrect in the first place?
I'll give this a try and report back.

I believe in previous releases they were required.

@thinkingserious
I've changed the constructor part to:
$this->mail = new SendGrid\Mail\Mail();

$this->mail
    ->setFrom($fromEmail, $fromName);

$this->mail
    ->setSubject($this->subject);

I then used the technique for inspecting the request body, which resulted in the following (I have redacted the values for privacy):
{
    "personalizations": [
        null,
        {
            "to": [
                {
                    "email": "[redacted]"
                }
            ],
            "dynamic_template_data": {
                "first_name": "[redacted]"
            }
        },
        {
            "to": [
                {
                    "email": "[redacted]"
                }
            ],
            "dynamic_template_data": {
                "first_name": "[redacted]"
            }
        },
        {
            "to": [
                {
                    "email": "[redacted]"
                }
            ],
            "dynamic_template_data": {
                "first_name": "[redacted]"
            }
        },
        {
            "to": [
                {
                    "email": "[redacted]"
                }
            ],
            "dynamic_template_data": {
                "first_name": "[redacted]"
            }
        },
        {
            "to": [
                {
                    "email": "[redacted]"
                }
            ],
            "dynamic_template_data": {
                "first_name": "[redacted]"
            }
        }
    ],
    "from": {
        "name": "Aiir",
        "email": "[redacted]"
    },
    "reply_to": {
        "email": "[redacted]"
    },
    "subject": "Subject line here",
    "content": [
        {
            "type": "text\/plain",
            "value": "[redacted]"
        }
    ],
    "template_id": "[redacted]",
    "categories": [
        "[redacted]"
    ],
    "substitutions": {
        "subject": "Subject line here",
        "preheader": "[redacted]",
        "title": "[redacted]",
        "content": "[redacted]",
        "footer": "[redacted]"
    }
}```

It looks like there is still a blank initial personalization, where it says `null`.

@gavrichards,
Could you please verify which version of this SDK you are using?
Also, as a quick workaround, you could add a personalizationIdex of 0 to attach to that default Personalization object.

@thinkingserious 7.2.1. Does the latest version offer any fixes for this?
Where would I use the personalizationindex of 0 that I'm not already?

@gavrichards,
I was thinking that perhaps you were on a version < 7. In the current version, I'm not seeing this behavior (a null personalization) in our tests, so perhaps I need to expand that test. I must be missing some edge case.
With regards to the Personalization index, I was referring to the code you first provided 3 days ago. In your loop, for the first personalization object you build, instead of building a new object, you would add those values to the first personalization. This might be more clear if you take a look at the request object generated by that code example.

@thinkingserious What I'm confused about is you said:

When you use the constructor with arguments we create an initial Personalization object behind the scenes at index 0.

So I took all arguments out of the constructor, presuming therefore that it doesn't create an initial Personalization object.
Therefore my code from a few days ago should work ok, where I create the first personalization object in the loop? But it is that that is resulting in the first personalization being null.

My apologies for the confusion @gavrichards.
What I'm trying to say is that you are correct, it should work if you take all the arguments out of the constructor. So I think there may be a bug. I am suggesting that you revert to your original code, with the caveat I mentioned, as a workaround while we debug.
I hope that helps!

@thinkingserious I've tried this, and while the first personalization isn't null anymore, the substitutions for that personalization aren't there.
e.g.
$address =<EMAIL_ADDRESS>$subs = [
  'first_name' => 'Andy'
];
$mail->addTo(new SendGrid\Mail\To($address), null, $subs, 0);

Results:
    "personalizations": [
        {
            "to": [
                {
                    "email"<EMAIL_ADDRESS>                }
            ]
        }, ...

Subsequent personalizations do have their substitutions, so it appears to just be an issue with the first personalization.

Thanks for the follow up @gavrichards,
It looks like there is a logic bug somewhere. The workaround I'd suggest until we get this sorted is to manually pass in the JSON object like so.
Thank again for taking the time and having the patience to work through this. All of the details you provided should help us pinpoint the issue.
With Best Regards,
Elmer

This doesn't seem to be fixed? I am sending the following data in my request and the global substitution is not working:
{
    "personalizations": [
        {
            "to": [
                {
                    "email"<EMAIL_ADDRESS>                }
            ],
            "substitutions": {
                "-EHASH-": "Subscriber1Hash"
            },
            "custom_args": {
                "subscriber_id": "39"
            }
        },
        {
            "to": [
                {
                    "email"<EMAIL_ADDRESS>                }
            ],
            "substitutions": {
                "-EHASH-": "Subscriber2Hash"
            },
            "custom_args": {
                "subscriber_id": "40"
            }
        }
    ],
    "from": {
        "name": "Owner",
        "email"<EMAIL_ADDRESS>    },
    "subject": "Test email",
    "content": [
        {
            "type": "text\/html",
            "value": "<p>Here is a test email"
        }
    ],
    "categories": [
        "author-initiated-update-notification"
    ],
    "custom_args": {
        "author_ids": "20",
        "product_id": "96",
        "version_id": "40",
        "content_id": "20"
    },
    "substitutions": {
        "-YEAR-": "2021"
    }
}

When I get the email, I see the text -YEAR- instead of the value.


Bug fix/replication fast lane

Pull Request Guidelines
Pull requests are an essential collaborative tool for modern software development.
The below list is intended to help you figure out whether your code is ready to be reviewed
and merged into ArangoDB. The overarching goal is to:

Reduce the amount of recurring defects
Reduce the impact to the other developer’s time and energy spent on defects in your code
Increase the overall autonomy and productivity of individual developers

Acceptance Checklist
The below list is not exhaustive, think thoroughly whether the provided information is sufficient.
Remove options that do not apply
Scope & Purpose
This PR should move the replication to fast execution lane. This way a replication insertion will be handled with higher priority as a client requested insertion.

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[x] Bug-Fix for a 3.4 port will happen after we validated in devel that this is ok
[ ] Strictly new functionality (i.e. a new feature / new option, no need for porting)
[ ] The behavior in this PR can be (and was) manually tested (support / qa / customers can test it)
[x] The behaviour change can only be verified via automatic tests

Related Information
(Please reference tickets / specification etc )

[ ] There is a GitHub Issue reported by a Community User:
[ ] There is an internal planning ticket:
[ ] There is a JIRA Ticket number (In case a customer was affected / involved):
[ ] There is a design document:

Testing & Verification
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This PR adds tests that were used to verify all changes:

[ ] Added Regression Tests (Only for bug-fixes)

[x] Added new C++ Unit Tests (Either GoogleTest or Catch-Test)

Did you add tests for a new RestHandler subclass ? Yes
Did you add new mocks of underlying code layers to be able to verify your functionality ? No

[ ] Added new integration tests (i.e. in shell_server / shell_server_aql)

[ ] Added new resilience tests (only if the feature is impacted by failovers)

Additionally:

[x] There are tests in an external testing repository (i.e. node-resilience tests, chaos tests)
http://jenkins01.arangodb.biz:8080/job/short-time-perfmance-test/ (currently blocked, will add a specific link tomorrow.
[ ] I ensured this code runs with ASan / TSan or other static verification tools

(Include link to Jenkins run etc)
http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/5011/

Think about whether the new code you added is modular enough to be
easily testable by unit tests written with GTest / Catch. It is not good if your feature is so interconnected
that it prevents other people from writing their own unit gests. It should be possible
to use your code in future without extensively mocking your classes.
A bad example that required some extensive effort would be the storage engine API.

Documentation

All new Features should be accompanied by corresponding documentation.
Bugs and features should furthermore be documented in the changelog so that
developers and users have a concise overview.

[x] Added a Changelog Entry
(Nothing is changed form user-perspective)
[ ] Added entry to Release Notes
[ ] Added a new section in the Manual
[ ] Added a new section in the http API
[ ] Added Swagger examples for the http API

CLA Note
Please note that for legal reasons we require you to sign the Contributor Agreement
before we can accept your pull requests.

@fceller Could you make sure we cover this with performance regression tests?


2789 integrate telemetry module

Description
This PR aligns the current telemetry with new feedback datasets by tracking:

Dataset publish action
#records when new records are created
Server error when something is wrong

LGTM! Just some minor comment

@gabrielmbmb I did some code refactoring regarding the track_data function and the global reference


Led plugin

Given the similarities between SPE and gain calibration a common plugin, to be integrated into strax (the new nT processor), will be used in XENONnT to access the LEDs raw data and return the variables needed for both of them.
The plugin requires having the 'raw_records' available.
To perform these analyses, a datasets of LED signals and a dataset of background are required. The latter is acquired with LED on in a setting with voltage low enough to not produce visible signals in the PMTs, i.e. 1.0V in XENON1T, compared to the ~3.5V for the SPE and ~4.2V for the gain. These values will probably change for nT.
Two functions are defined in the plugin, to get the amplitude and the area in a given window. The window is defined as a configuration parameter that is set to a default value in the plugin, but can be changed in the analyses by defining a new configuration setting. The functions do the following:

get_area, needed for the gain computation, sum the data in the defined window to get the area.

get_amplitude, needed for the SPE computation, take the maximum in two different regions, where there is the signal and where there is not.

N.B.: remember to set the number of PMTs to 494 when nT data will be available.

https://github.com/XENONnT/straxen/blob/2f5b45e6a4448a058c72a6a9fd62156e9c3d731f/straxen/plugins/led_calibration.py#L110
@GiovanniVolta @chiaracapelli  Do you know where the baseline is calculated? Is baseline is already corrected for raw_records['data']?

@GiovanniVolta @chiaracapelli I implemented the baseline correction in the area calculation as shown below. This should give us consistent gain values between my calculation and Chiara's notebook.
https://github.com/XENONnT/straxen/blob/7b512d978980acae9e6f3a72f3da302e248c13cf/straxen/plugins/led_calibration.py#L113

@GiovanniVolta @chiaracapelli I implemented the baseline correction in the area calculation as shown below. This should give us consistent gain values between my calculation and Chiara's notebook.
https://github.com/XENONnT/straxen/blob/7b512d978980acae9e6f3a72f3da302e248c13cf/straxen/plugins/led_calibration.py#L113

May I ask you Shingo to explain me how it works?

@GiovanniVolta @chiaracapelli I implemented the baseline correction in the area calculation as shown below. This should give us consistent gain values between my calculation and Chiara's notebook.
https://github.com/XENONnT/straxen/blob/7b512d978980acae9e6f3a72f3da302e248c13cf/straxen/plugins/led_calibration.py#L113

May I ask you Shingo to explain me how it works?

sorry that I forgot to attach some plots here to show you the changes.
Here, you can see two plots of Gain vs PMT ID for the previous one (without baseline correction calculated by @chiaracapelli ) and the new one with baseline correction.
It's clear that this correction gives the consistent estimation.

@GiovanniVolta @chiaracapelli I implemented the baseline correction in the area calculation as shown below. This should give us consistent gain values between my calculation and Chiara's notebook.
https://github.com/XENONnT/straxen/blob/7b512d978980acae9e6f3a72f3da302e248c13cf/straxen/plugins/led_calibration.py#L113

May I ask you Shingo to explain me how it works?

sorry that I forgot to attach some plots here to show you the changes.
Here, you can see two plots of Gain vs PMT ID for the previous one (without baseline correction calculated by @chiaracapelli ) and the new one with baseline correction.
It's clear that this correction gives the consistent estimation.

What I did is as follows;

raw_records['data'][:, left_noise:right_noise].sum(axis=1): integrating baseline inside the noise window
, and then divide by (right_noise-left_noise) samples to calculate average baseline amplitude for 1 sample
, and then multiply by (right - left) samples, which is signal integration length

@GiovanniVolta @chiaracapelli I implemented the baseline correction in the area calculation as shown below. This should give us consistent gain values between my calculation and Chiara's notebook.
https://github.com/XENONnT/straxen/blob/7b512d978980acae9e6f3a72f3da302e248c13cf/straxen/plugins/led_calibration.py#L113

May I ask you Shingo to explain me how it works?

sorry that I forgot to attach some plots here to show you the changes.
Here, you can see two plots of Gain vs PMT ID for the previous one (without baseline correction calculated by @chiaracapelli ) and the new one with baseline correction.
It's clear that this correction gives the consistent estimation.

What I did is as follows;

raw_records['data'][:, left_noise:right_noise].sum(axis=1): integrating baseline inside the noise window
, and then divide by (right_noise-left_noise) samples to calculate average baseline amplitude for 1 sample
, and then multiply by (right - left) samples, which is signal integration length

the notebook to make the above plot can be seen here;
https://github.com/XENONnT/analysiscode/blob/master/PMTs/Gain/calc_gain.ipynb

Thanks Shingo!

Hi @GiovanniVolta, for your SPE analysis, I think baseline also needs to be corrected. Maybe [0, 50] samples can be used for calculating baseline, and then [50, 125] samples can be used for calculating the maximum amplitude of noise.
https://github.com/XENONnT/straxen/blob/e598d73dd0a93a50e83a7a596c4bf66f0e59edde/straxen/plugins/led_calibration.py#L92

@GiovanniVolta , I checked it and I processed a run succesfully as if it were an LED-run.

@GiovanniVolta , I checked it and I processed a run succesfully as if it were an LED-run on one of our eventbuilders.

I am very happy! Thank you :)


Add support for the flex direction is set to row_reverse

and the support for the RTL environment.

Self reviewed


Documentation CSS

It looks like your documentation site has an issue with the z-index of the buttons. See screenshot.

URL: https://putyourlightson.com/plugins/sprig
Browser: Firefox 100.0.2
OS: macOS 12.3.1

Thanks, that appears to only happen on very wide screens, will make a note to fix this site-wide.


Add types

I think type VFileCompatible = VFile | VFileOptions | VFileContents should be in here. So after this pr is merged, I'll make another pr to discard it from unified.

Nice! 👍
As the previous two type additions (vfile-message, unified) caused some of the ecosystem to break, I’d first like to figure out how to prevent that from happening before adding this.

Absolutely!

maybe we need to change some other things in a major as well?

What do you have in mind @wooorm?

I do know that adding types to an API surfaces some weirdness, so if @Rokt33r finds things that are weird or hard to handle, we could change them now.

I don't' have any critical issues. But I sometimes thought it would be nice to have .freeze() method or immutable-vfile module.

@wooorm I've updated vfile-message!

This PR is good to go but unist-util-stringify-position needs to be updated with types first!


[RFC]: refactor blas/ext/base/dnanasum to follow current project conventions

Description
This RFC proposes refactoring @stdlib/blas/ext/base/dnanasum to follow current project conventions.
These conventions are outlined in more detail in https://github.com/stdlib-js/stdlib/issues/788. Namely, we want to migrate from C++ add-on interfaces to C add-on interfaces and then make various style and simplification changes.
Some example commits which perform most, if not all, of the requested changes include https://github.com/stdlib-js/stdlib/commit/d66d80cfcbab1da95cb5ae8cfae4a1fc4c5129d1 (saxpy),  https://github.com/stdlib-js/stdlib/commit/3c82fe7b6c0f9fd6ef02c86d6e2024d708ac8c14 (cswap), and https://github.com/stdlib-js/stdlib/commit/5b15c9675be434c0e11b1ec1e1f78d7b089abbcd (dasum).
Related Issues
Related issues #788, #1152.
Questions
No.
Other
No.
Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

I would like to work on this issue


How to use multiple prefix tuned models with parallel inference.

Hi Library error when I use muliptle prefix tuned models for parallel inference.
What are the adpaters which supports parallel inference and how to know their configuration.
Thanks

Hey, parallel inference (as well as all other adapter composition blocks) are currently only supported with the "original" bottleneck adapter configuration (all adapters using AdapterConfig). Support for other methods such as prefix tuning may be added in the future.


BOM after Push to Aisler.net not correctly loaded (incompleate assignment)

After uploading a project to Aisler.net even if all parts have a perfect matching MPN, the MPN seems not to be fully matched, see screenshot

After going between PCB and Parts the list gets filled up

But only leaving the project and returning to it will give the fully matches list with all known good MPSs that are in the design

Best Regards
CalM

Hi @calm4git, thanks a lot for the feedback on the BOM assigment process! We run the parts assignment in the background after upload, therefore you notice the step by step assignment as soon as you reload/return to the BOM page. I added an issue for an indicator about this to our internal development roadmap. Since it is not an issue of the KiCad plugin as such, I will close this issue for now.


Android App is crashing in Release build react-native 0.55.3  undefined is not an object (evaluating 'p.View.prototype.render')

Android: custom fonts not applied in debug build, and crashes in the release build
IOS: works fine in both debug and release builds
"react": "16.3.1",
"react-native": "0.55.3",
"react-native-global-props": "^1.1.3",

Here is the log:
07-13 23:12:20.344 23097-23120/? E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
Process: com.-.-, PID: 23097
com.facebook.react.common.JavascriptException: undefined is not an object (evaluating 'p.View.prototype.render'), stack:
setCustomView@458:161
@445:58
d@2:768
n@2:409
t@2:262
@306:191
d@2:768
n@2:409
t@2:262
@12:42
d@2:768
n@2:339
t@2:262
global code@464:8
    at com.facebook.react.modules.core.ExceptionsManagerModule.showOrThrowError(ExceptionsManagerModule.java:54)
    at com.facebook.react.modules.core.ExceptionsManagerModule.reportFatalException(ExceptionsManagerModule.java:38)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
    at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:160)
    at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
    at android.os.Handler.handleCallback(Handler.java:742)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
    at android.os.Looper.loop(Looper.java:157)
    at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
    at java.lang.Thread.run(Thread.java:818)

Thank you @sndkd I will look into this.

I also ran into an issue when upgrading react-native. I was using setCustomText, but the issue seems to be that Text.prototype is now undefined.

Take a look at this guys. I'm no longer using this library but this fix worked for me.
https://github.com/facebook/react-native/issues/2519#issuecomment-406150948

Can you please explain how exactly did you apply that fix and make this lib work again in RN 0.56?

As I mention above @dackom, I am no longer using this library. Having said that, the included link demonstrates how to add an empty defaultProps to Text and then you can modify any props available on the Text component.
My example demonstrates how to change allowFontScaling but you can do this for any property available on the Text component.

Yeah, but I dont know where should I put that piece of code to change default text properties. :-)

I putted this:
if (Text.defaultProps==null) Text.defaultProps = {}; Text.defaultProps.fontFamily="Open Sans";
...After imports and before export default class App... in App.js ...
And nothing happens. I also tried just for example color="#F00" ... and also nothing happened.
I tried to do same in index.js, but I needed to also import Text from react-native in order not to get error. But it still didn't work.

Only props can be changed with the proposed solution @dackom. Custom styles are not props. Please do honor the thread by sticking to the topic of the app crashing. The authors of the library are aware that it no longer works and there is no solution to modify fonts as far as I know.

It works if change setCustomText for this:
  const TextRender = Text.render
  const initialDefaultProps = Text.defaultProps
  Text.defaultProps = {
    ...initialDefaultProps,
    ...customProps
  }
  Text.render = function render(props) {
    let oldProps = props
    props = { ...props, style: [customProps.style, props.style] }
    try {
      return TextRender.apply(this, arguments)
    } finally {
      props = oldProps
    }
  }

I update setCustomText.js and it works:
import { Text } from 'react-native'

export const setCustomText = customProps => {
  const TextRender = Text.render
  const initialDefaultProps = Text.defaultProps
  Text.defaultProps = {
    ...initialDefaultProps,
    ...customProps
  }
  Text.render = function render(props) {
    let oldProps = props
    props = { ...props, style: [customProps.style, props.style] }
    try {
      return TextRender.apply(this, arguments)
    } finally {
      props = oldProps
    }
  }
}

Or create your own configuration file like this:
import { Text } from 'react-native'

////////////////// TEXT //////////////////
const customText = { style: { fontSize: 20 } }

setCustomText = customProps => {
  const TextRender = Text.render
  const initialDefaultProps = Text.defaultProps
  Text.defaultProps = {
    ...initialDefaultProps,
    ...customProps
  }
  Text.render = function render(props) {
    let oldProps = props
    props = { ...props, style: [customProps.style, props.style] }
    try {
      return TextRender.apply(this, arguments)
    } finally {
      props = oldProps
    }
  }
}
//////////////////////////////////////////

////////////// CONFIGURATION //////////////
const loadGlobalProps = () => {
  setCustomText(customText)
}
//////////////////////////////////////////

export default loadGlobalProps

@luisfuertes can you create a PR?

In the next 3 weeks I will be too busy, but the second week of October I will have time.
The PR is applying those changes in all setCustom components

I converted all custom functions thanks to @luisfuertes's code since I needed this today, feel free to use it : https://github.com/maieonbrix/react-native-global-props/
If you want I can submit a PR with better commits but I guess that @luisfuertes already got this so just tell me
Anyway a big thanks to to Andrew for this repo and Luis for this solution :)

@maieonbrix If you have them complete already, it would be very helpful. Thanks! :)


benchmarks.json: tweak dataset-serialize invocation

I hope that this passes CI (i.e., I hope that the automatic check does not require --iterations=3 --drop-caches=true.

E         -     "command": "dataset-serialize ALL --iterations=6 --all=true",
E         ?                                                    ^
E         +     "command": "dataset-serialize ALL --iterations=3 --all=true --drop-caches=true",
E         ?                                                    ^           +++++++++++++++++++
E               "flags": {
E                 "language": "Pyth

I find this rather inflexible, I think depending on the benchmark specifics we should be able to tweak things. What do we think?

Seems like iterations can be set as class attribute, and it seems like --drop-caches=true is hard-coded: https://github.com/voltrondata-labs/benchmarks/blob/16330feaeaa9d498f0fa08794045270798e118c1/benchmarks/_benchmark.py#L338

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.007%) to 87.222%

Totals

Change from base Build<PHONE_NUMBER>:
0.007%

Covered Lines:
1488

Relevant Lines:
1706

💛  - Coveralls


[BUG] Check data shape in predict-like functions

Reference Issues/PRs
Fixes #1774
Fixes #1775
Fixes #1936
What does this implement/fix? Explain your changes.
Adds a check to collection base classes which raises an error if length and channels does not match fit. Removed redundant check from interval base class.

@TonyBagnall @hadifawaz1999 do these changes seem reasonable? DLs are breaking, but i think that is more of a DL issues than the changes here.

@MatthewMiddlehurst not only DL seems dictionary based are failing too https://github.com/aeon-toolkit/aeon/actions/runs/10151952868/job/28072315499?pr=1865#step:7:260
is there something that these changes assume sub classes are doing ? because it seems it assumes n_timepoints is an attribute somewhere defined, which most sub classes don't do

It likely has to do with no longer allowing storage of metadata via predict. Just want to make sure the current changes are fine before we fix any of the broken stuff.

basic structure looks good to me

@chrisholder any issue with the cache change? currently I think it runs when collecting tests, or at least it did for some reason locally.

@hadifawaz1999 there was a conflict with the testing PRs, could you approve again?


The holy war

Looks like due to Visual Studio roots, project uses tabs for tabulation.
It might be a good idea to convert code to use of spaces instead to keep it more consistent on different developer machines.
Maybe we also should consider auto-formatting tools for check-in's to ease style guide following.
Thoughts?

It seems that project already uses tabs. I think let's just leave as it is.


How to test ？

I want to  know  how to test it? I just finish the train.Thanks.

Same question here. How to test trained model?


Add feedback_opt_in to online_applications

This aligns the staff app with the public app and ensures that the new feedback_opt_in field is recorded

:+1: nice and clean!


Signature Annotation for easier debugging.

The DPR computation involves tracking the updates to the signature region. This feature can be extended to obtain the label of the relevant test case from the elf and annotate the signature file with the appropriate instruction label. It will also be useful if this feature had a stand alone CLI and API interface for use with other tools.
(Link to original discussion)

DPR?
What I think we can't do is label trap signatures, since those don't have
fixed offsets.
IF we could do that, we could easily perform tests that have
nondeterministic results by running tests twice with each configuration and
checking that one or the other matches the vendor model.
On Wed, Feb 9, 2022 at 4:58 AM S Pawan Kumar @.***>
wrote:

The DPR computation involves tracking the updates to the signature region.
This feature can be extended to obtain the label of the relevant test case
from the elf and annotate the signature file with the appropriate
instruction label. It will also be useful if this feature had a stand alone
CLI and API interface for use with other tools.
(Link to original discussion
https://github.com/riscv-non-isa/riscv-arch-test/issues/230)
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-software-src/riscv-isac/issues/30, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJTFUKID2LAREE22T3DU2JQHLANCNFSM5N5NOZLA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Ah, yes, Data Propogation Report.
On Wed, Feb 9, 2022 at 2:58 PM Allen Baum @.***>
wrote:

DPR?
What I think we can't do is label trap signatures, since those don't have
fixed offsets.
IF we could do that, we could easily perform tests that have
nondeterministic results by running tests twice with each configuration and
checking that one or the other matches the vendor model.
On Wed, Feb 9, 2022 at 4:58 AM S Pawan Kumar @.***>
wrote:

The DPR computation involves tracking the updates to the signature
region. This feature can be extended to obtain the label of the relevant
test case from the elf and annotate the signature file with the appropriate
instruction label. It will also be useful if this feature had a stand alone
CLI and API interface for use with other tools.
(Link to original discussion
https://github.com/riscv-non-isa/riscv-arch-test/issues/230)
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-software-src/riscv-isac/issues/30, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJTFUKID2LAREE22T3DU2JQHLANCNFSM5N5NOZLA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Reference Issue

Getting this error just trying the quickstart code out.
Error CS0012 The type 'Browser' is defined in an assembly that is not referenced. You must add a reference to assembly 'PuppeteerSharp, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'.
We have PuppeteerSharp v3 installed and working, this error only shows when trying to use this plugin.

Same issue after updating PuppeteerSharp to version 3.0, I  get the Error CS0012 on .
            var extra = new PuppeteerExtra();
            var browser = await extra.LaunchAsync(new LaunchOptions {
                Headless = false,
                Devtools = true,
                DefaultViewport = null
            });

It seems Puppeteer-sharp-extra is no longer compatible with the newest PuppeteerSharp version.

Hi, I have fixed it in the next version which will be published in a few days

Thanks, for your great work.

Fixed by #20. Please update your NuGet package to version 1.3.0


Supply stays forever on "Preparing apk at path..."

My setup:

fastlane 2.64.0

supply(track: 'alpha',
  apk: "app/build/outputs/apk/app-release.apk",
  json_key: "fastlane/my-setup.json",
  skip_upload_metadata: true, # Dont upload this things at the moment
  skip_upload_images: true,
  skip_upload_screenshots: true)

After I run fastlane deploy_produciton --verbose logs stay forever at:
INFO [2017-11-09 13:54:56.58]: Preparing apk at path 'app/build/outputs/apk/app-release.apk' for upload...

can I do more to get more logs from fastlane?

Looks like this happens when you have a proxy in between

@caipivara So do things work for you when you remove the proxy?

@joshdholtz yeah.
It will be cool some message or maybe a warning on the readme saying this.


Extend Invocation API support

Our team needs a means to launch a JVM from Rust (in C JNI interface that functionality is provided by the Invocation API, that is already partly supported by jni-rs). I'd like to ask if anybody is currently working on it, and if not, if we could contribute the remaining parts? Are there any nuances we must consider when designing and implementing this functionality?

This is exactly our use case, I'm really interested in this development.
At the moment we are using an adapted version of the Jvm::new function from Rucaja to start the JVM, then we switch to jni-rs with JNIEnv::from_raw. It works fine for us. The only missing part in jni-rs is the link to the dynamic library, so we had to:

add links = "jvm" and build = "build.rs" to our Cargo.toml
add a #[link(name = "jvm")] extern "C" {} somewhere (e.g. lib.rs)
write a build.rs that configures the dynamic library location (an example is here, with a related issue)

In general, I think it can be very useful to have a look at Rucaja, because it already implements the "call JVM from Rust" part. A merge of the two would be really great, because most of the functionalities (call a method, call a static method, ...) are duplicated.

@fpoli , thank you a lot for the references, we'll definitely look at Rucaja closer to see how to make things work together!

OK, let me see if I have this straight, since I haven't looked at the invocation api at all since it's not part of our use case.

You want to start a JVM from rust and
That requires linking to a the JVM dynamic library

If implemented, it's probably something that we'll want to put behind a cargo feature, since unconditionally requiring linkage to the jvm lib might be undesirable. Otherwise, sounds like a great thing to have, and would make #61 actually doable.

I've started work on some additions to the invocation api in the invocation_api branch. Feel free to comment, test, PR, etc. from there and when we're all satisfied, I'll merge it to master.

Hi @jechase , we've used the tip from invocation_api branch for a while in some integration tests, and it seems to work properly. Is there anything you plan to put in it before releasing, maybe something we can help with?


Border region require more security (and have lower infastructure)

Somehow represent the difficulty of keeping less "tamed" places in line, and cause some extra challenge to expansion.

Question is; how?
States and modifiers can be checked and applied using various conditions and a hidden event that fires like every year.
The bigger question is, what type of modifier?


chore: upgrade react-hook-form to 7.28.1

Description
chore: upgrade react-hook-form to 7.28.1
Notice

[X] Have you followed the guidelines in our Contributing guide?
[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[X] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
N/A
Risk
Anything form related, like trade widget, send, etc.
Testing
Test that all forms work correctly

note for operations - this may look like a tiny benign change, but please test everything involving forms - sending, trading, importing wallets, error states etc

Looking at the CHANGELOG, this shouldn't produce any regression but the one place I can see where one might possibly be is async validation.

7.22.0: Browser native reset API will no longer be invoked when reset provided with value - grepped for all reset() calls and we're not calling it with a value anywhere
7.23.0:

useFieldArray change keyName is no longer required when field value contains id - we're not using this anywhere
useFormState will no longer fire state update after hook unmount -  that could produce regressions for us, but looking at our usages it shouldn't, since forms are reset when re-mounted
UseFormHandleSubmit type will infer formValues - that's just a type-level difference (https://github.com/react-hook-form/react-hook-form/commit/70f2902172c361a9f78d45fde6cbf3896bf06799#diff-eabbaef2281721f7cc5c6199ed1924c17fb1d3e33173f17156d6a7faea5ec176R524)and yarn type-check still passes for us

7.24.0: useController return prop: onChange, onBlur and ref will be memorized with useCallback - memoization shouldn't produce regressions
7.25.0: getFieldState get individual field state - this is a whole new method (https://github.com/react-hook-form/react-hook-form/commit/b5da7623c3052d25e5e455e78d9bbbd7612b1cea) which we're quite logically not using
7.25.2: onTouched mode will honor focusout event - we're not using onTouch anywhere
7.26.0: This one isn't documented in the CHANGELOG somehow and is mostly unrelevant internal changes, but I've spotted https://github.com/react-hook-form/react-hook-form/commit/ca02e47a29e2437012392f7dff8effec544ab930 which should in theory gives us more confidence with async validation, but can possibly break validation. We should test that async validation (e.g ENS names) has no regressions
7.27.0: new option for setFocus to select the entire field value - that's a new option (https://github.com/react-hook-form/react-hook-form/commit/eb4b5dc2b8dca23b72921ff3b2bac2ed8caa1a86#diff-a8e4a266dd4113147657e4db59e3ffad0f47c4d0515966004802b70e3e9ffa1aR40) which we are logically not using
7.28.9: register API options deps now support string - that just extends the behavior of register to support string | string[] vs only string[] previously (https://react-hook-form.com/api/useform/register). We're not using deps for validation when calling register() so that's also a non-concern.


Create solo Github Action for reusability and rapid adoption

Requested Feature
We need a publicly available Github Action (solo-gh-action) that can be used by everyone else to provision a solo network and run tests in their CI pipeline.
Business Need
Hedera community developers need the ability to quickly setup a solo network in their Github Action to run tests. Currently devs needs to duplicate the effort of setting up a solo network in their Github action. It would be far more efficient if the solo dev team could publish a Github Action (maybe later to Github Marketplace?) that everyone else can use.
It also provides more control about the updates with urgent fixes so that community don't need to spend too much time to use the latest solo version in their pipeline.
Additional Context
We already have code to setup solo network in Github Action, so it shouldn't take long. We just need to extract it in a new repo solo-gh-action, polish it up and publish.

NOTE: @nathanklick  helped @hendrikebbers create this: https://github.com/OpenElements/hedera-solo-action
We might be better to just enhance that project instead of creating another action.


Adding a Feature to Connect on a Video Call for Guidance

What feature?
I propose adding a feature that allows users to connect on video calls for guidance and mentorship. This feature would enable members to schedule one-on-one or group video sessions to seek advice, collaborate, or discuss projects.
Why is this feature needed?
Personalized Guidance: Many developers benefit from personalized support and mentorship, and video calls offer a more effective way to communicate than text-based chat.
Enhanced Collaboration: This feature would facilitate real-time collaboration among developers, improving teamwork and project outcomes.
Community Building: Video calls can help foster a sense of community by allowing members to connect on a deeper level.
It can be paid too!
Add screenshots
Add screenshots
Something like this:

Code of Conduct

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

📢 Invitation to Join the DevDisplay WhatsApp Community!
We are excited to invite you to join the WhatsApp community of DevDisplay, where developers and contributors come together to collaborate and share their ideas.
Collaborative Support: If you are interested in working together with extensive support, we encourage you to join our community.
Open Source Contribution: If you would like to contribute to the DevDisplay open-source project, your participation is welcomed in our WhatsApp group.
By joining, you will have the opportunity to connect with like-minded individuals, discuss project developments, and contribute to our shared goals.
For more information and to join the community, please visit: Join DevDisplay WhatsApp Community.
We look forward to your participation!

Hey @priyachau12 , Let's start working on this issue.
& be a part of core team of our organization.


Windows elevated / non-elevated installation should be user selectable

Users should be able to choose whether or not to install the chef-dk msi with elevated (root) privileges.  Additionally, whatever install directory is chosen should be validated as to whether or not it has a space since Ruby and its toolsets behavior erratically when executables are located in a path that contains spaces.
From an MSI perspective, this forum post describes how this can be authored via Wix: http://stackoverflow.com/questions/14339372/wix-non-admin-installer-tutorial.

Not doing this.


Upgrade third-party services

Body
In our installers, we currently use some third-party services which are outdated:

CouchDB
InfluxDB
Consul

These should be upgraded to the latest version.
StreamPipes Committer
I acknowledge that I am a maintainer/committer of the Apache StreamPipes project.

Do you already have an impression on how many adaptions are required on our end?
Can we cover all three in one issue?


SDA-8382|feat:Add tuning config support

Add create/list/describe/update/delete tuning configs
Add tuning config support for node pools

UX
This PR adds a few new commands
rosa list tuning-configs -c <clusterid> [-o json]
rosa create tuning-config -c <clusterid> --name --spec-path <specFile>
rosa delete tuning-config -c <clusterid> <name>
rosa describe tuning-config -c <clusterid> <name> [-o json]
rosa edit tuning-config -c <clusterid> <name> --spec-path <specFile>

And an additional parameter for node pools
rosa edit machinepool -c <clusterid> nodePoolName --tuning-configs="config1,config2"

And the relevant support for interactive mode for creation/edit. In node pool interactive mode, user is presented with the list of the tuning config existing in the cluster.
References

general design doc
JIRA: SDA-8382

@wgordon17 PTAL if it looks ok to you in terms of UX

Overall looks good, is there any task to includes docs for this? I feel like it is necessary. Also should any of this be hidden for a while?

Cool, I think this looks good 👍 Any reason that there's no rosa create machinepool --tuning-configs? Or is that implied?
@gdbranco Yes, we'll definitely need follow up docs
@andreadecorte This is HCP-only, right? This has no applicability to Classic

Cool, I think this looks good 👍 Any reason that there's no rosa create machinepool --tuning-configs? Or is that implied?

Just forgot to add in the description, it's there of course. Thanks for noticing

@gdbranco Yes, we'll definitely need follow up docs
Agree, I expect this to follow the normal ROSA doc flow? @wgordon17 do you have already something tracking this?
@andreadecorte This is HCP-only, right? This has no applicability to Classic
Correct. But good point, I will do the check directly here to avoid being rejected by the backend. Let me fix that

@gdbranco I don't think they should be hidden, it should be just a normal feature.

/hold
waiting for backend production load

Newly minted docs card: https://issues.redhat.com/browse/OSDOCS-5816

/lgtm

/unhold


Error while validating the java-spring-boot2 appsody stack on PPC64LE

I am getting following error while validating the java-spring-boot2 appsody stack:
[Container] docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/.appsody/appsody-controller\": stat /.appsody/appsody-controller: no such file or directory": unknown.
[Error] Error in 'appsody test': exit status 127

and
Docker] [ERROR]
[Docker] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[Docker] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Docker] java.io.FileNotFoundException: ../*.jar (No such file or directory)
[Docker]        at java.io.FileInputStream.open0(Native Method)
[Docker]        at java.io.FileInputStream.open(FileInputStream.java:212)
[Docker]        at java.io.FileInputStream.<init>(FileInputStream.java:152)
[Docker]        at java.io.FileInputStream.<init>(FileInputStream.java:104)
[Docker]        at sun.tools.jar.Main.run(Main.java:319)
[Docker]        at sun.tools.jar.Main.main(Main.java:1300)
[Docker] The command '/bin/sh -c /project/util/check_version build  && /project/java-spring-boot2-build.sh package  && /project/java-spring-boot2-build.sh createStartScript' returned a non-zero code: 1
[Error] exit status 1
[Error] exit status 1
[Error] exit status 1

** Steps to reproduce the behavior: **

Clone stacks repo
Go to incubator/java-spring-boot2 directory
execute appsody stack validate command
See error

Environment Details :

OS: Linux
ARCH: ppc64le
Version: 0.3.22
CLI version: appsody 0.5.8
Stack you are using (including the version): java-spring-boot2 0.3.23 or 0.3.22

PFA full log at - appsody-validate-0.3.23.log
Any pointers in this regard would be of great help !

I guess the problem is with the following command :
Running command: docker run --rm -p 5005:5005 -p 8080:8080 -p 8443:8443 -p 35729:35729 --name testRunContainer -u 0:0 -e APPSODY_USER=0 -e APPSODY_GROUP=0 -v /root/.appsody/stacks/validating-java-spring-boot2/.:/project/user-app -v /root/.m2/repository:/mvn/repository -v appsody-controller-0.3.4:/.appsody -t --entrypoint /.appsody/appsody-controller dev.local/appsody/java-spring-boot2:0.3 --mode=run
When I modified this command and executed manually, it worked
docker run --rm -p 5005:5005 -p 8080:8080 -p 8443:8443 -p 35729:35729 --name testRunContainer -u 0:0 -e APPSODY_USER=0 -e APPSODY_GROUP=0 -v /root/.appsody/stacks/validating-java-spring-boot2/.:/project/user-app -v /root/.m2/repository:/mvn/repository -v /root/go/src/github.com/appsody/controller/package/.:/.appsody -t --entrypoint /.appsody/appsody-controller dev.local/appsody/java-spring-boot2:0.3 --mode=run
Please note the change:
-v appsody-controller-0.3.4:/.appsody
changed to
/root/go/src/github.com/appsody/controller/package/.:/.appsody

When you execute appsody run/test/debug, the CLI should download appsody controller and set up a named volume for you.
Looks like this is not happening as expected in this case.


use OrderDict because csv.DictReader returns a dict after version 3.7

See: https://github.com/python/cpython/pull/8014

LGTM, I'll apply the same fix for the statistics script.

I don't want to spoil the fun here, but are we sure we're fixing the right thing? The end result seems to be a dict() anyway
https://github.com/opnsense/plugins/blob/dbb697a2ec48265f47b22333fbd57afba62d5cc3/net/haproxy/src/opnsense/scripts/OPNsense/HAProxy/lib/haproxy/cmds.py#L333

@AdSchellevis imho not just a dict() is needed, but an OrderedDict for move_to_end() to work at
https://github.com/opnsense/plugins/blob/c149e55aa691768206a08b49229d174051b9f858/net/haproxy/src/opnsense/scripts/OPNsense/HAProxy/lib/haproxy/cmds.py#L329-L331

@kulikov-a it won't stick to the end when casting to dict() later on :) (if it does, it's pure luck)

@AdSchellevis ah, got it, thanks. but shouldn't the order be preserved if (starting from 3.7) it is declared that the dict() preserves the insertion order (https://docs.python.org/3/whatsnew/3.7.html)?

@AdSchellevis
This fixes the bug and don´t modifiy the existing structure as casting to a dict should preserve the order. But maybe me, @kulikov-a  and the python guys are overlooking something? Do you have any other information?

@kulikov-a I kind of missed that item in the release notes, my point just is that if the order doesn't matter in real life, best don't try to make it look like it does..... trusting ordering in named array types is often quite dangerous and prone to errors. Eventually it wraps into a json container, which likely doesn't care about order either.
https://github.com/opnsense/plugins/blob/c149e55aa691768206a08b49229d174051b9f858/net/haproxy/src/opnsense/scripts/OPNsense/HAProxy/lib/haproxy/cmds.py#L87
It's not my code, if @fraenki choses to accept it I don't mind, spending years on reverse engineering of all sorts of weirdness in our old code just makes my eyes hurt.

The code is not refactored yet. My primary goal was to get the feature to work. In the next iteration it will be cleaned.

@AdSchellevis thanks for the explanation. thought that json.dump() just inherits the dict() behavior and now the order should be preserved for json too (https://docs.python.org/3.8/library/json.html).
@andeman sorry for the discussion. just trying to learn something

@kulikov-a that is good to know, but since it wasn't earlier, its likely safe to assume order doesn't matter (in which case someone could just add "id" to the container and be done with it)

I can confirm that it fixes the maintenance page, so the targeted issues is solved.


Block remote code execution

User Story:
As a host, I don’t want users to be able to arbitrarily execute code on my server to ensure the integrity of the polls and ensure user’s can’t hack me/ cheat.

An old issue (#124) describes the problem in more detail:

With access to perform: and similar messages, one could wreak havoc and circumvent any security measurements put in place. We should guard against this, possibly by only allowing messages to be sent that are implemented directly on the object that's messaged (and not inherited handlers).


Return OneDSpectrum when appropriate

The OneDSpectrum class was implemented previously to provide usable slices of the form cube[:,y,x], but the related numpy functions were never updated to provide similar access.  Now they do.
We are close to the point of providing users with dangerous rope, though: cubes can easily be in surface brightness units, which make sense to average but lose meaning when summed unless the pixel size (pixels-per-beam) is accounted for.  We're still no worse than any other software, but an important goal is to seamlessly incorporate the radio_beam information so that "summed" or "averaged" spectra really have the right units.

Coverage increased (+0.84%) to 66.32% when pulling f887cf626162bf55a39cf37b7ee725bbfad8faaa on keflavich:numpyfunc_to_spectrum into 58306aeb94844695c353f2afc4923895bc842f06 on radio-astro-tools:master.

This PR has revealed that spectral_cube requires numpy>=1.8 to use the .nan(mean|std) functions and axis=(1,2) syntax.  I'm therefore deprecating support for older versions.  Most of spectral_cube will still work with these, but I don't think it is essential to support these in a beta-ish package like this.

Coverage increased (+0.84%) to 66.32% when pulling fd1cb7c279b041420bc5f670aba8e9fb46e1907e on keflavich:numpyfunc_to_spectrum into 58306aeb94844695c353f2afc4923895bc842f06 on radio-astro-tools:master.

@astrofrog @ChrisBeaumont any comments on the loss of np < 1.8?

We can add tests back in later, but they will require some pytest.skipif marks

Fine by me
On Sunday, February 15, 2015, Adam Ginsburg<EMAIL_ADDRESS>wrote:

Merged #188 https://github.com/radio-astro-tools/spectral-cube/pull/188.
—
Reply to this email directly or view it on GitHub
https://github.com/radio-astro-tools/spectral-cube/pull/188#event-236019759
.

--

Chris Beaumont
Senior Software Engineer
Harvard Center for Astrophysics
60 Garden Street, MS 42
Cambridge, MA 02138
chrisbeaumont.org

I'm also fine with requiring Numpy 1.8+


Add RSS and JSON Job Feeds

#24 This PR adds JSON and RSS responses to the job postings index and show pages.  It also adds subscription links on the sidebar and rss link tags in the head.  JSON data is serialized to conform to json.api standards.

Thanks @jereinhardt. Happy Hacktoberfest!


TAF - Different time formats

Expectation
start_time.dt and end_time.dt is always formatted in the correct ISO 8601 format
Result
The format differs from location to location.
EBBR
_https://avwx.rest/api/taf/EBBR_
Raw TAF: EBBR 050501Z 0506/0612 06011KT CAVOK
"start_time": {
  "repr": "0506",
  "dt": "2020-05-05T06:00:00+00:00Z"
}

ELLX
_https://avwx.rest/api/taf/ELLX_
Raw TAF: ELLX 050500Z 0506/0612 04010KT CAVOK
"start_time": {
  "repr": "0506",
  "dt": "2020-05-05T06:00:00Z"
}

It becomes especially difficult when this time has to be parsed for different weather stations. Tools like Moment.js fail.
Furthermore, the notation for EBBR does not appear to be correct. The letter "Z" should never be added when using "+00:00".

I will need to add some more tests in the core library to figure out what is causing some date time objects to be created without a timezone, but I've made a change to the JSON formatter that should fix this problem's symptom for the end-user.
https://github.com/avwx-rest/avwx-api-core/commit/779cffd4826e43d12c0bf1e0fb43dca5d43c361a


Add support for testing JavaScript JSON objects key-by-key

Problem: Testing for exact JSON objects is fraught with many grave difficulties, such as orderIds, dates and other dynamic data constantly changing.
Need: The ability to compare two JSON objects, one from JavaScript, one from the Behat tests, on a key-by-key basis, including the keys one wants to test, and ignoring the rest.

Resolved by #28


Stdin warning makes programs stuck

Context: https://discord.com/channels/725351238698270761/799982808122523648/962805007248392192

httpie has stopped working for me, even after this fix (I installed it with brew install --HEAD httpie).
Example request:
http -v --debug google.com
HTTPie 3.1.1.dev0
Requests 2.27.1
Pygments 2.11.2
Python 3.10.2 (main, Feb  2 2022, 05:51:25) [Clang 13.0.0 (clang-13<IP_ADDRESS>)]
/opt/homebrew/Cellar/httpie/HEAD-83803db/libexec/bin/python3.10
Darwin 21.4.0

<Environment {'apply_warnings_filter': <function Environment.apply_warnings_filter at 0x106332b90>,
 'args': Namespace(),
 'as_silent': <function Environment.as_silent at 0x106332a70>,
 'colors': 8,
 'config': {'__meta__': {'about': 'HTTPie configuration file',
                         'help': 'https://httpie.org/doc#config',
                         'httpie': '1.0.3'},
            'default_options': []},
 'config_dir': PosixPath('/Users/nachosoto/.httpie'),
 'devnull': <property object at 0x10630e9d0>,
 'is_windows': False,
 'log_error': <function Environment.log_error at 0x106332b00>,
 'program_name': 'http',
 'quiet': 0,
 'rich_console': <functools.cached_property object at 0x106325db0>,
 'rich_error_console': <functools.cached_property object at 0x106325120>,
 'show_displays': True,
 'stderr': <_io.TextIOWrapper name='<stderr>' mode='w' encoding='utf-8'>,
 'stderr_isatty': True,
 'stdin': <_io.TextIOWrapper name='<stdin>' mode='r' encoding='utf-8'>,
 'stdin_encoding': 'utf-8',
 'stdin_isatty': True,
 'stdout': <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>,
 'stdout_encoding': 'utf-8',
 'stdout_isatty': True}>

<PluginManager {'adapters': [],
 'auth': [<class 'httpie.plugins.builtin.BasicAuthPlugin'>,
          <class 'httpie.plugins.builtin.DigestAuthPlugin'>,
          <class 'httpie.plugins.builtin.BearerAuthPlugin'>],
 'converters': [],
 'formatters': [<class 'httpie.output.formatters.headers.HeadersFormatter'>,
                <class 'httpie.output.formatters.json.JSONFormatter'>,
                <class 'httpie.output.formatters.xml.XMLFormatter'>,
                <class 'httpie.output.formatters.colors.ColorFormatter'>]}>

>>> requests.request(**{'auth': None,
 'data': RequestJSONDataDict(),
 'headers': <HTTPHeadersDict('User-Agent': b'HTTPie/3.1.1.dev0')>,
 'method': 'get',
 'params': <generator object MultiValueOrderedDict.items at 0x1065d6260>,
 'url': 'http://google.com'})

GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: google.com
User-Agent: HTTPie/3.1.1.dev0

httpie has stopped working for me, even after this fix (I installed it with brew install --HEAD httpie).

Hey @NachoSoto thanks for the report! I can't seem to reproduce your issue (on a fresh environment). When did you start experiencing these problems? (it seems like your issue is irrelevant from this by the way, as this issue was for POST/PUT etc. that was originating from stdin).

Sorry you're right! This was an unrelated issue caused by a local proxy.

For future reference, you might want to specify --timeout=30 (or something like that) in your ~/.config/httpie/config.json so that it won't make you want indefinietely and let you know about the potential issue.


'No makefile found' error when running make

I'm trying to compile this from source on  Ubuntu 16.04.2 LTS:
test@test:~$ git clone git://github.com/texane/stlink.git && cd stlink
test@test:~/stlink$ ls
build  ChangeLog.md  cmake  CMakeLists.txt  debian  doc  etc  flashloaders  include  LICENSE  Makefile  README.md  scripts  src  stlinkv1_macosx_driver  tests  usr
test@test:~/stlink$ make
[RELEASE]
make[1]: *** No targets specified and no makefile found.  Stop.
Makefile:27: recipe for target 'release' failed
make debug throws no errors though.
Any ideas?

You need to have CMake. Then the toplevel makefile generates makefiles with cmake and starts the build process. It is documented in https://github.com/texane/stlink/blob/master/doc/compiling.md#build-from-sources

Closing this, as it is documented. Feel free to comment if you have further questions.

Is there anything other than the package cmake that I need?

trinch@marko:~/stlink$ dpkg -s cmake
Package: cmake
Status: install ok installed
Version: 3.5.1-1ubuntu3

Yes you need libusb as mentioned in the documentation.

trinch@marko:~/stlink$ dpkg -l libusb-1.0*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                  Version                         Architecture                    Description
+++-=====================================================-===============================-===============================-================================================================================================================
ii  libusb-1.0-0:amd64                                    2:1.0.20-1                      amd64                           userspace USB programming library
ii  libusb-1.0-0:i386                                     2:1.0.20-1                      i386                            userspace USB programming library
ii  libusb-1.0-0-dbg:amd64                                2:1.0.20-1                      amd64                           userspace USB programming library development files
ii  libusb-1.0-0-dev:amd64                                2:1.0.20-1                      amd64                           userspace USB programming library development files
ii  libusb-1.0-doc                                        2:1.0.20-1                      all                             documentation for userspace USB programming

I compiled this without using  makefile and I can succesfully use stlink on Ubuntu. It's merely the makefile that isn't working for me.

@athirasivaraj screaming for free help on the internet is not going to help you, probably you are missing some needed linux knowledge. Good luck.

Issue closed as invalid and not related to the st-link project.


Bottleneck in mel / segment calculation?

I gave this a try today on a large number of audio files with batch sizes of 16 and then 32.
If I watch nvidia-smi dmon while the batch processing runs, I see very low GPU memory/core usage for large periods of time, then a spike in both, followed by a batch of text.
I speculated that there was a bottleneck in the decoding of the audio files into mels - but it looks to me like you do that at the start. I'm not familiar enough with what is calculated on and off the GPU and when here. Is it possible there's a lot of work involved decoding, eg, an MP3 that can be threaded that I'm missing somewhere? GPU utilization is only near maximum for maybe like 5% of the time the program is running which isn't my typical experience with ML resource utilization?

You're absolutely right that there's an audio decoding bottleneck. Currently the audio files are decoded serially at the beginning of a batch with ffmpeg. This could and should be parallelized, as it can take a long time for long (or many) audio files.
The GPU usage is actually quite descent once the audio files are decoded and the system begins transcription, but that part of the pipeline can't start until the tensor arrays with the decoded audio are prepared. Other parts of the pipeline definitely warrant investigation, but I think this explains what you're observing.
Would you be interested in submitting a PR? The fix should be as simple as replacing the serial decoding of a batch of audio file-paths here with a multiprocessing implementation: https://github.com/Blair-Johnson/batch-whisper/blob/76b3f818fb94a7c18c37d2ffecf71d7c69182749/whisper/transcribe.py#L335

I can probably do that for the calculation of mels, but that isn't where I'm seeing the bottleneck as I run transcribe - which was confusing to me. If that's the only place audio decoding is taking place, then something else is CPU bound that I'm not understanding.
I didn't do a good job of explaining. When run in verbose mode which a batch size of 32, text is output let's say every 30 seconds or so. nvidia-smi dmon during that 30 second window looks something like below. Then there will be a spike of GPU usage (the 99% here and 37% memory), and then some text will pop out.
       0    60    58     -    19     0     0     0  5005  1581     1    10    36     -     0     0     0     0   405     4     0    61    58     -    35     7     0     0  5005  1441     1    10    36     -     0     0     0     0   405     2     0    60    58     -    14     0     0     0  5005  1378     1    10    36     -     0     0     0     0   405     3     0    61    58     -    16     0     0     0  5005  1378     1    11    36     -     0     0     0     0   405     2     0   226    66     -    99    37     0     0  5005  1403     1    10    35     -     0     0     0     0   405     2     0    72    60     -    28     6     0     0  5005  1747     1    10    36     -     0     0     0     0   405     2     0    72    59     -    15     0     0     0  5005  1769     1    10    35     -     0     0     0     0   405     4     0    72    60     -    19     0     0     0  5005  1771
Meanwhile I a show a single 5ghz CPU core pegged. So I'm trying to figure out what is CPU bound for the 30 seconds that prevents the GPU from working at 99% core usage and 37% memory more of the time.
If it was just the initial calculation of mels, wouldn't I only see that spike for new files? This pattern happens in the middle of a group of 32 files - then, yes, there is a slowdown while mels are calculated initially - but these are long periods of time here for decoding.
I don't really understand the model and what's being calculated where but thought you might and could point me in the right direction?

Here's one slow portion, I think:
https://github.com/Blair-Johnson/batch-whisper/blob/76b3f818fb94a7c18c37d2ffecf71d7c69182749/whisper/decoding.py#L704-L707
As it's looping through samples, this is particularly slow but doesn't seem to be part of the model inference or taking place on a GPU that I can tell? I'm not familiar enough with the where the matrix math gets done here.
I'll keep investigating, but this appears to be very slow relative to the surrounding work.

Good catch, I think that I found the issue. On this line... https://github.com/Blair-Johnson/batch-whisper/blob/76b3f818fb94a7c18c37d2ffecf71d7c69182749/whisper/decoding.py#L493
...the logit filter lists are are all initialized with the same list object. As a result, each new batch of tokens for each audio file was being filtered by all logit filters introducing redundancy and potential accuracy issues. I'll post a PR with that fix and the ffmpeg multiprocessing modification. Let me know if that improves performance on your end.

Ah, That probably also explains why I have a list of no_speech_prob in the output as opposed to just the single probability I expected and get with a normal whisper run.

I think the large disparity between our resource use was because I was using model=base and you were using large. When I switch to large, I get much higher GPU utilization which makes sense. ApplyTimestampRules is definitely the bottleneck with those lower parameter models.
Your fix here did raise GPU utilization but in the results I still have an array of no_speech_prob corresponding to the current batch size (which changes as various audio files fall off from length differences).
I'll open another issue if I pin this down but there's also something going on with multiple model.decode() runs for each decode_with_fallback() toward the end of the batch - probably something to do with shifting file sizes. I can't tell yet if there's missing transcriptions and it's just falling back or what.

I updated the PR to address the no_speech_prob issue, let me know if you have any issues. As for the multiple model.decode() executions, could you verify whether they are being called because of temperature fallback? The loop checks to see if the compression ratio of generated text is too high to avoid repetitive transcription, which can happen sometimes. If it's being triggered unnecessarily regardless of the threshold we set, then that's an issue.


MunchJS outputs 'undefined' to views

Dear @jmrocela & JSMunch community,
Although I have an open issue about jQuery`s JSDom missing setters parameters, I've modified the source code inserting the missing parameters as needed.
I've also applied the fix for missing .usage file and MunchJS is currently running without warnings or errors.
However, there is a strange behaviour I could not identify yet that makes MunchJS outputs 'undefined' to views.  What may be happening?
note: JS and CSS files are written correctly but they're nothing without a working view.
Thanks in advance!

@arlusf,
this is my biggest problem right now!
Here's my current scenario:

Clone munchjs repo:

$ cd ~
$ git clone https://github.com/jmrocela/munchjs.git

note:
    "jquery": "~1.8.3",
    "jsdom": "~0.6.5",

Install MunchJS globally:

$ npm install -g .

note the . at the end of the line

Apply these 2 fixes:

1. Modifyjsdom's source code, adding the required parameters ([mentioned here](https://github.com/jmrocela/munchjs/issues/21))
2. Modify munchjs souce code, adding the fix [described here](https://github.com/jmrocela/munchjs/pull/24)

Execute MunchJS for a simple view:

$ cd /w/quickstart/src
$ munch --view index.html

Which outputs fine, as everything is ok. But, instead of a processed file, the content of index.html.munched is:
undefined

Yes, it is right, one work, 9 bytes. I really don't know what to do, lol, is this expected? I have not found any fix for this in the repo's known issue tab.

@arlusf, sorry but I think changing JSDom version to 3.1.2 makes this error happen. Sorry for this confusion. I'm now using the original package.json and the problem won't happen.

I got similar issues, and also the files that I target are renamed with undefined at the end, like
index.htmlundefined
how this can be fixed?
thanks!


Example

Hi and thanks for the work!
I'd like to use your library but cant find an example or even understand its purpose. Could you provide some code in order to use it properly? Thanks :)

@JeromeDesseaux  did you manage to use this package? I am getting some erros.

Hi @igoralves1,
No, I didn't. I finally made my own Amazon requester signing requests on my own. Feel free to reuse this code
My code is made for requesting books products by their barcode (ISBN). I think you may adapt it for your own needs. Anyway, this code is pretty straight forward and you may understand it quite easily.
Feel free to send me another message if needed :)

Hi @igoralves1, @JeromeDesseaux 👋
Sorry for the late response. I'm rewriting parts of this library, and will add documentation and examples!

Finished API/documentation update in 4191d0f


use [RLMResults count] in Realm notification listener crash

How frequently does the bug occur?
Sometimes
Description

Stacktrace & log output
No response
Can you reproduce the bug?
-- select --
Reproduction Steps
No response
Version
10.49.1
What Atlas Services are you using?
Local Database only
Are you using encryption?
No
Platform OS and version(s)
iOS 17.4.1
Build environment
Xcode version: ...
Dependency manager and version: ...

The code:
` if notificationToken == nil {
notificationToken = focusMsgs.observe(keyPaths: [\Message.isRead]) { [weak self] (changes: RealmCollectionChange) in
switch changes {
case .initial:
print("[notificationToken] initial")
case .update(let results, _, _, _):
print("[notificationToken] update")
let count = results.count // Crash here!!!
updateUI(count)
            case .error(let error):
                print("[notificationToken] error")

            }
        }
    }`

Do you think you can extract a minimal repro that we can use to investigate? There's nothing obviously wrong with your code or the calls mentioned in the stacktrace, so it's not clear what could be causing the crash. If we had a repro we could debug, that would go a long way to fixing it.

Can you include the code for this getRealm(for: Message.self)?
Is this a local or sync'd realm
Are you using any kind of threading, await/async or @Actor?


First draft of re-working types for #1317

Signed-off-by: Christopher Grote<EMAIL_ADDRESS>

recheck


[Perf] Improve JS runtime package version reporting

/azp run tools - perf-automation - tests

/azp run tools - perf-automation - tests

/azp run tools - perf-automation - tests

/azp run tools - perf-automation - tests


bluetooth: host: add checks for connection types

Fail gracefully if an HCI event of one type arrives for a handle of a different connection type.  The requested types are currently based on what fields are used, not on the usage context, in order to keep every correct use so far still working.
A warning is logged if the connection identified by the handle does not match the requested connection type.

Fail gracefully if an HCI event of one type arrives for a handle of a different connection type. The requested types are currently based on what fields are used, not on the usage context, in order to keep every correct use so far still working.
A warning is logged if the connection identified by the handle does not match the requested connection type.

This seems to guard against a faulty controller, right? Has this been an actual issue, or just defensive programming?


MVP of a new /addKey route which allows fastauth users to export their account to BitteWallet

Introduces a new route /addKey that allows FastAuth users to initiate a transaction to add a full access public key to their account, and guides them to export the corresponding private key to Bitte Wallet

@shelegdmitriy @jackson-harris-iii do you mind to test this out, by logging into the preview build with a fast auth account, and provide feedback on the UX?

For me, the flow itself works great! Great job @charleslavon 👏 But importing private key to Bitte wallet fails -> loom video

@shelegdmitriy @jackson-harris-iii do you mind to test this out, by logging into the preview build with a fast auth account, and provide feedback on the UX?

flow works well. I think there are some UI things that could be improved, but other than that things on dev.near work well.
I too was unable to import my key into BItte wallet.

Hey @charleslavon, I copied over and refactored your MVP code here: https://github.com/near/near-discovery/pull/1273
Does it make sense to close this PR now?


Creating a new doc should navigate to viewing the doc

steps to reproduce:

create a new document with id test-new-doc
hit save
you're redirected to the document list view

what would be better:
3.1. the URL changes from db-name/new/editing to the created doc, db-name/test-new-doc
3.2 then the user is viewing the newly created doc, instead of the all docs page

Done Kevin.


Calling deregister with mio should remove signal hooks

So I've been playing with the mio crate for signal_hook and have the desire to register a signal, listen for it, then unregister it again at a later point. It seems like currently the recommended behavior for doing that is to call signal_hook::cleanup::cleanup_signal(SIGNAL).
I personally find this a bit confusing, given that mio has a built-in deregister function. Wouldn't it make sense for the mio backend to register signal hooks on register and reregister and to reset them to the default on deregister?
I'm also a bit confused about the structure of the API, since calling signal_hook::unregister registers an empty action instead of resetting it to the OS defaults. Wouldn't it make more sense to have this usecase covered by register instead?
It might also make things a bit cleaner to have methods take references to structs, instead of passing structs as parameters, so SigId::unregister instead of unregister(id: SigId), since that would probably make the "flow" of the API a bit more clear? The way it is right now, I just see an unregister method and wonder how I get a SigId so I can remove a signal, which doesn't make much sense.

Hello
I'm not entirely sure about where your confusion comes from, but I'll try a guess.
So, signal hook has these low-level register and unregister calls. These are really low level and allow manipulating the hooks directly and when you register, you get the SigId for future deregistration.
Then there's mio with its Evented trait, that has the register/reregister/deregister. There's a bit of clash of terminology around that in signal-hook-mio, but both kind of developed independently of each other and eventually „met“ each other in the signal-hook-mio. These are, however, fully independent of each other, the register of signal hook has nothing to do at all with register from mio.
How this crate is intended to be used:

You create the Signals, with bunch of signals to watch, or add them later on. The struct internally holds the relevant SigIds, you don't have to touch them.
Then, this thing can be plugged into mio with poll.register. That in turn uses the Evented::register and similar. These, however, are just the integration into watching for readability. Same as if you create a mio::TcpStream, you don't connect or disconnect by registering or deregistering it for polling.
Once you get the readability event, you „read“ the available signals by calling signals.pending on it.
If you no longer want the signals, you simply drop the Signals structure. It unregisters signals on drop, using the internally-held SigIds.

As for actually removing signals. It's not exactly true that unregister „registers“ an empty action. Signal hook keeps possibly multiple hooks for the same signal. It can happen that if you remove all of them, then nothing is left to be called in the signal handler. But it is not reset to OS default for two reasons:

The general habit of many libraries that touch signal handling is to call sigaction and chain-call the previously installed action. Signal-hook does the same and it could be possible to return that one. But there's no possible way to know if someone actually does this to us. That could, quite accidentally, remove some other, completely unrelated, signal action from the chain.
By adding and removing hooks, getting „accidentally“ to empty state and having it to reset to some other action would be inconsistent behaviour.

Therefore, calling a cleanup_signal is an explicit action left up to the application developer, because they are the only ones knowing this can safely be done.

These are, however, fully independent of each other, the register of signal hook has nothing to do at all with register from mio.

And I think this exactly is the problem.

If you no longer want the signals, you simply drop the Signals structure. It unregisters signals on drop, using the internally-held SigIds.

Sure, but I am not able to remove any signals. All I can do is recreate the signal handler entirely if I want to change them, which requires reregistering the mio source and does not cause any signal handlers to be called in the future. How is one supposed to mutate the signals with the mio crate?

And I think this exactly is the problem.

As in, you now see the misunderstanding, or in, you'd want to tie them together? As for the latter, it would seem really weird to me (and I'm not sure if it's even possible). As I look at it, the TcpStream doesn't disconnect on deregister either. It still can receive and send data, you just don't get notified about it. It probably should be the same ‒ if you deregister, you'd still receive the signals and queue them, but not get notified of them.

Sure, but I am not able to remove any signals.

If I understand you correctly, you're saying that the Handle has add_signal, but not a remove_signal? That's true. That's across all the signal-hook crates and it's mostly because there are some challenges and nobody felt it was useful enough to go and solve them (unregistering signals seems to be much less common need than registering them). As the API goes, I'm ok if you want to add a remove_signal, but I'd want you to consider all kinds of possible race conditions when doing so in the PR and be sure it doesn't break anything (it might turn out it actually works in some simple way out of the box, but I would at least want the author to say why it happens to work and why no problem can happen).
What you can do now is create multiple Signals structure, each one for its own signal. Then you can just drop the whole relevant Signals structure. You can even have multiple for the same signal, for different parts of the application, for example. Having multiple signals inside the same structure is mostly relevant to the blocking iterator inside signal-hook, mio can be used to select between independent ones.

All I can do is recreate the signal handler entirely if I want to change them, which requires reregistering the mio source and does not cause any signal handlers to be called in the future.

I don't understand what you mean by „does not cause any signal handlers to be called“. Can you demonstrate what you mean?

As in, you now see the misunderstanding, or in, you'd want to tie them together? As for the latter, it would seem really weird to me (and I'm not sure if it's even possible). As I look at it, the TcpStream doesn't disconnect on deregister either. It still can receive and send data, you just don't get notified about it. It probably should be the same ‒ if you deregister, you'd still receive the signals and queue them, but not get notified of them.

As in the lack of integration seems to cause problems that I do not see a solution for with the current API.

I'd want you to consider all kinds of possible race conditions when doing so in the PR and be sure it doesn't break anything

That just sounds like being setup for failure. Removing a signal is a perfectly normal usecase for signal handling, I don't see why this is dismissed as something so outlandish.

I don't understand what you mean by „does not cause any signal handlers to be called“. Can you demonstrate what you mean?

Sure, take this code (compressed):
// Setup mio
let mut signals = Signals::new(&[SIGTSTP])?;
poll.registry().register(&mut signals, SIGNAL_TOKEN, Interest::READABLE)?;

// start mio loop...

// Attempt to remove the sigtstp signal and self-trigger it again.
fn handle_sigtstp() {
    signal_hook::cleanup_signal(libc::SIGTSTP).expect("unexpected signal state");
    unsafe {
        libc::kill(process::id() as i32, SIGTSTP);
    }
}

// Register custom sigtstp handler again.
fn handle_sigcont() {
    signals.add_signal(libc::SIGTSTP).unwrap();
}

That's basically the gist of what I want to do. I've tried several different things like dropping all the signals and re-creating them and of course I've also attempted to reregister to mio after the events have changed. But none of this produced working code, the SIGTSTP handler is never called again once it is removed.
This has lead to me reading the documentation for cleanup_signal:

Once called, registering new hooks for this signal has no further effect (they'll appear to be registered, but they won't be called by the signal).

So I've made the assumption that this kind of stuff doesn't seem to work? Which raised the question how does one make it work with mio. I've sifted through the API with all its different register/unregister methods and beyond the trivial setup signals and start mio, I'm not sure how this is supposed to be interacted with.
How does one remove a signal and add it again? signals.reregister() doesn't do it and signals.remove/add doesn't seem to do it either. That's why I'm confused about the interaction with mio. It seems nebulous to me how one is supposed to interact with the mio signal handling, rather than just setting it up and hoping it will be good enough for the rest of the application lifetime.

As in the lack of integration seems to cause problems that I do not see a solution for with the current API.

I believe it's not the lack of integration, but lack of parts of the API. See below.

That just sounds like being setup for failure. Removing a signal is a perfectly normal usecase for signal handling, I don't see why this is dismissed as something so outlandish.

You seem to misunderstand what I'm trying to say (maybe I'm not saying it the best possible way).

Signal handling is hard, so any such change is hard and needs certain amount of care. Usually more care than people suspect before submitting a PR. So I'm trying to warn in the sense „I'll be happy to have a PR implementing it, but expect it to take a while and expect some pointy questions in the form of "is that actually safe, will that always work?"“. If the add_signal didn't exist and someone wanted to add it, I would also want all kinds of race conditions considered. I want the code that is already there to work, not almost-always-work.
More people need adding signals than removing signals. I maintain the library in my free time, so I prefer covering my own needs first. Other people also seem to solve primarily their use cases. I do not dismiss the use case, I agree with it, but nobody needed it yet, or wasn't motivated enough to write it.

All in all, you can either submit a PR (with the warning that it might be some amount of work), or might wait until I manage to squeeze it into my schedule, but that might take some time.
Now, to your example (I'm finally starting to see what you're trying to do):
The cleanup_signal, as it is implemented now, is just the bare minimal implementation to support the use case „I press CTRL+C once to get a graceful shutdown, but the signal handler is completely removed at that point, so when it gets stuck and I CTRL+C again, it just terminates right away.“ People do it at shutdown, so it being irreversible is not a problem. However, the idea is (and always was) to eventually make it reversible, so that if you cleanup_signal, and register a new one again, it would plug the signal handler back in. This just haven't happened yet, because again, nobody was motivated enough to pick it up. That's actually what #30 is about.
As mentioned above, the cleanup_signal can't happen automatically and one would still need to do that by hand to get the default signal handler.
However, if you simply wanted to pause receiving/handling that signal for a while, without returning to the default, you could just do something like:
// Setup mio
let mut signals = None;
handle_sigcont()?;

// start mio loop...

// Attempt to remove the sigtstp signal and self-trigger it again.
fn handle_sigtstp() {
    signals = None;
    // Whatever else
}

// Register custom sigtstp handler again.
fn handle_sigcont() -> Result<(), Error> {
    signals = Some(Signals::new(&[SIGTSTP])?);
    poll.registry().register(signals.as_ref_mut().unwrap(), SIGNAL_TOKEN, Interest::READABLE)?;
}

If you do need returning to the default handler in between, this is what you'd need to do:

Solve #30 first, as it is the actually missing part. That's not about mio or integration, it's simply part that's haven't been finished.
You'd still need to tear down and recreate (or add the remove_signal call to Handle) the Signals, because that structure would otherwise „believe“ the library is still initialized to receive the signal and would not re-register itself (mostly, cleanup_signal removes all the hooks without letting owners of the hooks know).

However, if you simply wanted to pause receiving/handling that signal for a while, without returning to the default, you could just do something like:

The entire goal is to go back to the default, so that the application is actually suspended. So just not reacting to it doesn't help.

Solve #30 first, as it is the actually missing part. That's not about mio or integration, it's simply part that's haven't been finished.

Sure, by solving #30 it would probably make this library usable for me. Though I still find its API questionable.
Do you want to close this issue and open a separate, clean one for allowing the removal of signals from mio's Signals structure? Since this issue has been a bit of a tangent about all kinds of stuff.

Though I still find its API questionable.

The whole signal handling API is a nightmare, to be honest, and some of it leaks. I think the fact that resetting to default doesn't happen on its own is caused by the fact that you, as an application developer may make the assumption you're the only one around touching signals. But inside a library I can't make that assumption, I have to let the application developer make that claim through the API.

Do you want to close this issue and open a separate, clean one for allowing the removal of signals from mio's Signals structure? Since this issue has been a bit of a tangent about all kinds of stuff.

I think I'll do that. The #30 is the must-have for your use case, I'll add another one for the remove_signal, that is in a sense a nice-to-have (the code would be nicer with it, but can be made work with just #30).
Do you want to give one (or both) of them a try, or shall I try to find some time for them eventually?
Once again, thanks for the example, I wasn't getting what the actual problem was until then.

But inside a library I can't make that assumption, I have to let the application developer make that claim through the API.

It's not only about the signal handling part though. It's also about a lack of clear structure and transparency within the library.
Things like having the register and unregister methods available in the root, while taking and creating a SigId, which makes it difficult to see from the docs how the API is supposed to be used.
It also seems like SigId is not an accurate handle either, at least I can't see a Drop impl that would call unregister and it's Copy. So I'd assume that unregister must be called manually. That's okay, but something that isn't immediately obvious.
Then there's the 4 different functions to remove a signal. You have unregister, which takes a SigId, cleanup_raw, which removes the OS signal handler but doesn't remove the hooks, cleanup_signal which removes both and unregister_signal which just removes the hooks without touching the signal handling. The amount of time it takes to read through all of these just to figure out you can't actually unregister a signal cleanly is nothing short of infuriating.
Of course it's fine to have things unimplemented and work in progress, nothing just immediately exists and is perfect. But I personally found that the features missing from signal_hook were amplified by an API that did not make it transparent if the thing I want to do is unsupported, or if I'm just doing it in the wrong way. When there's about a dozen different combinations to try, that just makes troubleshooting very difficult.

Do you want to give one (or both) of them a try, or shall I try to find some time for them eventually?

I can look into #30, but I'm not sure how far I'll get on that since I didn't plan to go for a detour. If it's non-trivial I'm probably going to look for an alternative solution to my problem.

It's not only about the signal handling part though. It's also about a lack of clear structure and transparency within the library.

I think I see what you mean. The library did grow over time a bit, and it is result of some experimentation. Some restructuring, or at least better documentation might actually help. That's probably a topic for yet another issue.
I think I would have a workaround for your problem, though:
What you're trying to do (if I understand correctly) is not unregister a signal. What you're trying to do is invoke the default signal handler, right? Now, the POSIX API doesn't really have a good answer to that, but the workaround seems to be something in form (pseudocode):
current_signal = signal(SIG_DFL);
raise();
signal(current_signal);

That has bunch of problems, including things like „What if I get the signal from someone else in between“ (this is not atomic operation and it affects other threads and so on), but you could still do it while keeping signal-hook around.

Now, the POSIX API doesn't really have a good answer to that, but the workaround seems to be something in form (pseudocode):

Yes, that code looks like it should work by sidestepping signal-hook completely. That would be a bit unfortunate though. But in my particular application that wouldn't cause any problems at all.

That would be a bit unfortunate though.

That's the reason why I cal it a workaround, not a solution. I would want to support your use case, but I suspect that will take some time to get to, this is meant for the meantime so you're not blocked on it.


[Feature] Add Java agent plugin for Jdk Threading classes

Please answer these questions before submitting pull request

Why submit this pull request?
[ ] Bug fix
[x] New feature provided
[ ] Improve performance

Codecov Report

Merging #4067 into master will decrease coverage by 0.04%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #4067      +/-   ##
==========================================
- Coverage   26.82%   26.78%   -0.05%
==========================================
  Files        1134     1141       +7
  Lines       24986    25052      +66
  Branches     3607     3622      +15
==========================================
+ Hits         6703     6709       +6
- Misses      17686    17746      +60
  Partials      597      597

Impacted Files
Coverage Δ

...ng/apm/agent/core/plugin/match/HierarchyMatch.java
0% <ø> (ø)
:arrow_up:

...lking/apm/agent/core/plugin/match/PrefixMatch.java
0% <0%> (ø)

...king/apm/plugin/jdk/threading/ThreadingConfig.java
0% <0%> (ø)

.../apm/network/trace/component/ComponentsDefine.java
0% <0%> (ø)
:arrow_up:

...ent/core/plugin/match/logical/LogicalAndMatch.java
0% <0%> (ø)

...ugin/jdk/threading/ThreadingMethodInterceptor.java
0% <0%> (ø)

...gent/core/plugin/match/logical/LogicalOrMatch.java
0% <0%> (ø)

...jdk/threading/ThreadingConstructorInterceptor.java
0% <0%> (ø)

...re/plugin/match/logical/LogicalMatchOperation.java
0% <0%> (ø)

.../apache/skywalking/apm/agent/core/conf/Config.java
71.42% <0%> (-0.92%)
:arrow_down:

... and 21 more

Continue to review full report at Codecov.

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

I think we should write a blog(en) about this feature on the official website, with your demo codes and screenshot. I think people will love this. Including this will work with many thread pool, right?

I think we should write a blog(en) about this feature on the official website, with your demo codes and screenshot. I think people will love this. Including this will work with many thread pool, right?

Sure, I’ll try if I can get some time

@kezhenxu94 You got an error in your test case, could you recheck?

@kezhenxu94 You got an error in your test case, could you recheck?

because of the removal of config item in agent.config, checking


How to establish channel attention?

In 2.2. Attention Mechanisms of this paper mentations:
"our approach considers a more efficient way of capturing positional information and channel-wise relationships to augment the feature representations for mobile networks."
However, I`m confused how to establish channel attention?

Two 1x1 convs are used to build the inter-channel relationship.

Thank for your answer!

t

Why does the  two 1*1 convs have this effect，how can them build the inter-channel relationship?

1*1的效果可以替代SEblock中的两个全连接层吗？

Channel attention is based on the capability of capturing global information. We do this by using two different types of pooling operations.

Channel attention is based on the capability of capturing global information. We do this by using two different types of pooling operations.
Thank you for your reply. Do you think it will improve the effect of semantic segmentation when it is used in U_Net?

According to my knowledge, the answer is yes.