Why require CrudRequest...?

Bug report
What I did:
I created a FormRequest like I would normally do with Laravel...via art make:request StoreFooRequest.  I updated the CRUD controller's store() method to use this request.
What I expected to happen:
Once the validation on the form request passed, then the new data would be stored.
What happened:
Type error: Argument 1 passed to Backpack\CRUD\app\Http\Controllers\CrudController::storeCrud() must be an instance of Backpack\CRUD\app\Http\Requests\CrudRequest or null, instance of App\Http\Requests\StoreFooRequest given
What I've already tried to fix it:
Not much, other than to take a quick look at Backpack\CRUD\app\Http\Requests\CrudRequest to see what was so special about it.
Backpack, Laravel, PHP, DB version:
More or less the latest, across the board.
Extra:
Perhaps I've missed something, but Backpack\CRUD\app\Http\Requests\CrudRequest appears to add no value.  It seems that Backpack\CRUD\app\Http\Controllers\CrudController::storeCrud() should require Illuminate\Foundation\Http\FormRequest (or some sufficient contract/interface).
I'd be happy to put together a quick PR, but I wanted to find out if this would be a waste of time before I did it and to perhaps figure out why this might not be a good idea.

You are probably right that there’s no extra in current crud request provided by backpack.
We try hard to enhance backpack without producing breaking changes. By requiring a special backpack crud request we can ensure that further updates (where we put extra value to the request class) will not break anything by currently requiring you to inject a subclass of our own request class.
The current overhead changing the superclass of your generated request class is just a small bit in opposite of changing every request class in every project when updating backpack (and requiring some extra functionality).

Thanks for the prompt reply.  I understand what you're saying, but in 2017 it seems odd to choose such a solution that requires the "current overhead [of] changing the superclass of your generated request class".  Introducing a contract that allows for any subclass of Illuminate\Foundation\Http\FormRequest would seem to be the "better" way to go.
Also, it's worth noting that if no request object is passed in, then the backpack code creates an instance of Illuminate\Foundation\Http\FormRequest rather than Backpack\CRUD\app\Http\Requests\CrudRequest:
    {
        $this->crud->hasAccessOrFail('create');

        // fallback to global request instance
        if (is_null($request)) {
            $request = \Request::instance();
        }

Interesting....
I would like to see a change, but I guess as long as there's the desire to keep open the ability to "enhance backpack without producing breaking changes", then we're stuck having to have an otherwise modular package further pervade other aspects of a solution.
I'm not entirely sure how I can utilize Backpack in this manner, however, without duplicating code, if I'm to be able to build my application as I had hoped.  I have a simple Laravel-based API with a Vue-based SPA front-end.  I would like to have the API as its own project, the SPA as its own, and the admin as its own.  To do this would require having my models and certain "basic/fundamental" functionality in their own repository/package.  Having FormRequests for my API that I could re-use for administrative purposes would work fine this way.  But, now I have to introduce CrudRequest into my "basic/fundamental" functionality for no other reason that because it's required (for some potential future changes) by Backpack....or I have to repeat the same validation code between projects.
Not fun.
Alright...I guess that's enough rambling for me this morning.  I'll accept the overhead/cost/imposition for now and maybe spend some time/thought to come up with a solution that still allows for the we-might-add-something-at-some-time mentality.
Thanks again.  :-)

@tabacitu any opinions/suggestions on that?

I can't see any particular justification for having our own request class; in looking at support requests I'd say this (un)feature probably causes us more pain.

@lloy0076 I took a (quick) look through the issues and PRs before I submitted this issue and I've again looked through the issues since your post.  You seem to imply that "this (un)feature probably causes us more pain" because you're seeing people encounter some sort of confusion or difficulty or something in the support requests.
May I ask, where are you seeing these support requests...?

@OliverZiegler Thanks for allowing for further discussion.  Much appreciated.  :-)

Oh, I tend to listen in on the Gitter conversations and fairly much anyone who tries to override the request classes gets gnarled by this. Whilst many people open support-like issues on Github (they really should be on StackOverflow), this one seems to not land that often here.

Well hearing this, I think we should remove this...
@tabacitu ?? :)
@telkins wanna create a PR for this? But Remember all the stubs that need to be changed accordingly ;)

@telkins, pardon me, but i have a curiosity: why would you create an additional/other request file, i am assuming you used 'php artisan backpack:crud object' which generates the controller, model and request. what does the CRUDRequest is missing or not allowing?

@AurelDragut just suppose you have the backend (with backpack) and some kind of API. You could use the same request object for both. but as we currently need to subclass the CrudRequest class you either duplicate your code or need to use the backpack class for your API. As people sometimes try to split backend and API in different submodules (or even projects) and use packages this leads to bad atomicity of code.
See also this part of @telkins comment:

I'm not entirely sure how I can utilize Backpack in this manner, however, without duplicating code, if I'm to be able to build my application as I had hoped. I have a simple Laravel-based API with a Vue-based SPA front-end. I would like to have the API as its own project, the SPA as its own, and the admin as its own. To do this would require having my models and certain "basic/fundamental" functionality in their own repository/package. Having FormRequests for my API that I could re-use for administrative purposes would work fine this way. But, now I have to introduce CrudRequest into my "basic/fundamental" functionality for no other reason that because it's required (for some potential future changes) by Backpack....or I have to repeat the same validation code between projects.

@OliverZiegler, i keep on reading your comment and i am trying to figure out what i am missing (i haven't worked yet on so advanced projects). So we would need two different requests: one for administrative stuff and one for normal stuff. Never tried it yet, but coulndn't we condition the use of a request or another based on something?
if (\Auth::user()->hasRole('admin') use App\Http\Requests\AdminRequest as StoreRequest
else use App\Http\Requests\NormalRequest as StoreRequest

both requests should have the instance of the same parent request.

@AurelDragut the issue is that currently we rely on the Backpack\CRUD\app\Http\Requests\CrudRequest without any benefit and we could just type hint the store and upgrade methods in the Base CrudController with the Laravel Illuminate\Foundation\Http\FormRequest class so no one needs the CrudRequest class here.
About your code: I'm not sure if switching use statements depending on some other code is good practice (and im even not sure if this even works...)

@OliverZiegler, so it comes down to using Backpack\CRUD\app\Http\Requests\CrudRequest as we do now (which would allow you to add future updates as you said before) or using Illuminate\Foundation\Http\FormRequest (in which we would have full liberty).

@AurelDragut Hi.  Good questions, but I think @OliverZiegler did a better job of answering than I could have.  Still, I'll take a swing combining some of his words with my own.  :-)
There's nothing inherently wrong with using or requiring Backpack\CRUD\app\Http\Requests\CrudRequest, but to do so without providing any benefit is questionable...at best.
Why would people have Illuminate\Foundation\Http\FormRequest instead of Backpack\CRUD\app\Http\Requests\CrudRequest...?  A couple of reasons jump to mind, including the one I mentioned earlier which @OliverZiegler also noted again:

First, one may have simply had a project and decided to add Backpack to it in order to enhance it.  In this case, any existing form request classes would have to be changed..."without any benefit".  It's all cost and no joy.  :-)
Second, one might have a project like the one I described, which would be composed of three different repositories, basically: an API, an admin tool (Backpack), and the "common bits" that each would use.  The API and the admin tool would use the same models for those models that were common between them.  Likewise, the API and the admin tool would use the same form requests for those form requests that were common between them.  If an API allows for a consumer to add a user, then one might validate using a StoreUserRequest form request class.  If the admin tool is allowed to do the same, then there's a good chance it would use the exact same logic.  DRY dictates that one would try to reuse the same form request class.  One can either make the common one Backpack\CRUD\app\Http\Requests\CrudRequest, which would be weird since the API and common repo/package wouldn't need to know anything about Backpack....or one would have multiple copies of the same functionality.

It's not the end of the world to have to make all form requests Backpack\CRUD\app\Http\Requests\CrudRequest classes....but without any benefit, it's just extra work.
So...it seems like the consensus is that if it's not providing any value/benefit, then let's not incur any costs on the Backpack users.
Hopefully that helps clarify a bit and/or give you a bit of a different angle/perspective.  :-)

@AurelDragut that's exactly the point ;)
@telkins good "sum up" ;)
Beside the suggestion of @telkins providing some kind of contract we require you to implement in your Illuminate\Foundation\Http\FormRequest subclass. But this contract would be empty at the moment...
In conclusion we have the following three options:

leave everything like it is (seems like the worst option)
switch to a contract users need to implement (this would make update-features easier but currently also has no benefit, also it seems like a breaking change)
switch to type hinting Illuminate\Foundation\Http\FormRequest(and edit stubs accordingly)

I would prefer number 3.
@tabacitu @lloy0076 should we do this?

@AurelDragut I'll jump in and try to answer since I'm already here.  :-)
One can continue to use Backpack\CRUD\app\Http\Requests\CrudRequest.  It's easy to do and for many/most, it will make zero difference going forward.  If/when some value/benefit is added to the class, you'll get it for free without any bumps.
If, however, you choose/need to use Illuminate\Foundation\Http\FormRequest, then everything should go just as nicely as with the other option (if the proposed changes are made, of course).  However, as soon as Backpack\CRUD\app\Http\Requests\CrudRequest is required (again), there will be bumps.  The idea would be that there will now be value/benefit to such a requirement, however, which would presumably be worth the trouble.  :-)

@OliverZiegler Thx.  :-)
Btw, I am trying to pack up and get out of here.  It's a bit late where I am and I need to get home.  :-)
I agree with you and prefer number 3.  I think number 2 might be good, but I haven't been able to find a good solution in my head.  I also wouldn't mind doing it.  I just need to find time.  :-)
For now, though...I gotta run.  I'll check back in later....

First, one may have simply had a project and decided to add Backpack to it in order to enhance it. In this case, any existing form request classes would have to be changed..."without any benefit". It's all cost and no joy. :-)

Which is kinda obvious/normal (it's called adaptation), also we would do the same thing in the opposite way when switching from backpack requests to laravel requests.
Anyway I guess you know better which is the best choice for long term and I also think option 3 is the best despite the consequences on current projects.

@AurelDragut switching to Illuminate\Foundation\Http\FormRequest is no issue for any current project. As Backpack\CRUD\app\Http\Requests\CrudRequest extends the former, switching the type hints will not break anything.

Thx, @OliverZiegler. I logged in on my phone to say the exact same thing. :-)

Yeah, sorry, i forgot about that.

Some people just don't want to use form requests, though....and one could equally argue that Illuminate\Http\Request is the one to aim at.

Well... as we build it currently like this:
if (is_null($request)) {
    $request = \Request::instance();
}

i would really just use Illuminate\Http\Request

@lloy0076 It looks like the controller has the request already (from the constructor) and it doesn't appear to use anything from the FormRequest, either.  So, going with Illuminate\Http\Request seems even better.  And, relying on $this->request when no request is passed in to the store/update Crud methods might be a better fallback for when no request is passed in...?  I'm not sure I understand the meaning/need/value of passing in any request (Request, FormRequest, or CrudRequest) to the store/update Crud methods...?  Anyone know what the thought is behind that?

@telkins as you could manipulate the request data before calling parent:storeCrud($request) (in a subclass of CrudController) we need it as a parameter.
Default Laravel has the request injection in the route functions and we should stick to that and not introduce (bother) devs to use $this->request instead. (That also doesn't feel very laravely)
As I understand $this->request and the middleware closure in the __construct is only needed for the setup function to have session data and stuff like Auth available.

@OliverZiegler Thx for the explanation.  Makes sense to me, more or less.  :-)

Hi guys,
Long thread - took me a while to catch up.
I think you guys are right - we've had this for a few years and nothing new came up to be included in CrudRequest, I think it's safe to say nothing will probably come up in the near future. So I agree with what @telkins said, CrudRequest might not be necessary.
Another reason CrudRequest existed is because I noticed that (without it) people forgot to include this in their custom Requests:
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        // only allow creates if the user is logged in
        return \Auth::check();
    }

I previously thought that without it, theoretically anyone could send a POST request to the /admin/entity/create URL, without being authenticated, and they would insert an item. update would work similarly. And I think that's actually how things worked back then. I usually have good reasons before doing stuff. I think this was before the admin middleware and automatic CSRF fields, in Backpack's father, Dick, and back when Laravel didn't check for the existence of the authorize() method. I don't know, doesn't really matter.
Please correct me if I'm wrong - I don't think this authentication verification is necessary anymore:

We already make sure that the user is authenticated in the admin middleware. Laravel Form Request's authorize() method is now just to go deeper, check if the user is an admin, check if the user is not trying to edit himself, stuff like that.
Laravel now checks that the authorize() method exists in the Request file. Otherwise it won't run.
All forms have a CSRF field, so if the user logs out but submits the form afterwards, they get a "page expired" screen (just tested it).

So I think:

it's super-safe now to allow people to use their own Form Request files, instead of extending CrudRequest;
we don't actually need CrudRequest anymore; but we need to keep it in the package for backwards-compatibility;

So I'd say "option 3" is the winner: change CrudRequest with vanilla Request in CrudController. So exactly what @OliverZiegler 's PR #1129 does (thanks a lot).

I don't think we MUST enforce authentication at all, to be honest; it might behoove us to make it EASY to enforce authentication but that is different from enforcing it.

That being said, I wonder how you got to this error, @telkins :
Type error: Argument 1 passed to Backpack\CRUD\app\Http\Controllers\CrudController::storeCrud() must be an instance of Backpack\CRUD\app\Http\Requests\CrudRequest or null, instance of App\Http\Requests\StoreFooRequest given
For the life of me, I couldn't get it, with zero changes in Backpack, before merging @OliverZiegler 's PR. Here's what I did:

created a new Form Request using php artisan make:request TestTagRequest
checked that that request extends Illuminate\Foundation\Http\FormRequest instead of \Backpack\CRUD\app\Http\Requests\CrudRequest; it does;
placed my rules() in the request file;
in TagCrudController I used the new TestTagRequest instead of the TagRequest generated by the generator:

-use App\Http\Requests\TagRequest as StoreRequest;
+use App\Http\Requests\TestTagRequest as StoreRequest;
-use App\Http\Requests\TagRequest as UpdateRequest;
+use App\Http\Requests\TestTagRequest as UpdateRequest;

My result - it works. No error...
Did you do anything differently?

I think that is a bit weird, @tabacitu, CrudController uses backpack request and so should your TagCrudController which extends the CrudController, maybe there is a different setting about errors your config ignores.

@tabacitu Sorry for taking so long to reply.  I was quite sick when you posted your last comment and I think it just got lost in the rubble, so to speak.  :-)
Anyway, I have to agree with @AurelDragut ...."that is a bit weird".  Something's not right.
When Backpack\CRUD\app\Http\Controllers\CrudController::storeCrud() is called, it requires . an instance of Backpack\CRUD\app\Http\Requests\CrudRequest.  So, if you pass an instance of Illuminate\Foundation\Http\FormRequest, then PHP should react as described here: http://php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration
The method, storeCrud() has the following declaration:
use Backpack\CRUD\app\Http\Requests\CrudRequest as StoreRequest;

...

    public function storeCrud(StoreRequest $request = null)
    {
        ...

So, if storeCrud() receives an instance of Illuminate\Foundation\Http\FormRequest "then an error is generated: in PHP 5, this will be a recoverable fatal error, while PHP 7 will throw a TypeError exception."
I can redo everything, but I'm 99.9% certain that this is simply how it works, so if you're not seeing it, then my guess is that the test is flawed somehow.
P.S. I hope I'm not coming across rudely here in "black and white".  I said, "99.9% certain" because I've been proven wrong so many times in my life that I know it's always possible.  I'm confident and certain, but this wouldn't be the last time I've been wrong about something.  ;-)  Anyway, the tone of this post is meant to be positive and friendly.  I hope you've taken it that way.  :-)

@telkins @tabacitu I'm tempted to hit this with a big hammer and refer to #1129 but I'm not sure if the conversation hasn't stopped.
Nor am I sure what conclusion has been come to 😿

@telkins thank you for the kind reply. Don't worry about coming across rude, you certainly didn't. Even if you had, tough skin, been doing this for a while :-)
What I was trying to explain (and failed) is that switching to Illuminate\Foundation\Http\FormRequest should not be a breaking change for any current project. As Backpack\CRUD\app\Http\Requests\CrudRequest extends Illuminate\Foundation\Http\FormRequest, switching the type hints will not break anything. Just tried it again. It does not. So I've just merged #1129. If I made a bubu, I'm very very sorry. But I'm pretty certain about this - tried it over and over again, on multiple systems.
Cheers! Thanks for the great collaboration here.

@lloy0076 Looks like the conversation's come to an end...finally.  :-)
@tabacitu Thanks.  Glad I didn't come across rude.   And thanks for the great effort...!  :-)


[WIP] wayland-rs-0.20.0

Currently WIP, complete rework of the libs to significantly improve the APIs and reduce the unsafe code use, as well as pave the road for a full-rust implementation of the protocol.
TODO:

commons:

[x] API documentation
[x] Crate documentation

scanner:

[x] client code generation
[x] server code generation

client:

[x] object implementation & dispatching
[x] connection initialization
[x] multiple queues handling (non-send support)
[x] convenience code for handling globals
[x] wayland-egl
[x] wayland-cursor
[x] API documentation
[x] Crate documentation

server:

[x] object implementation & dispatching
[x] non-send implementation support
[x] server initialization
[x] client tracking
[x] multiple event queues & event sources
[x] API documentation
[x] Crate documentation

... as well as pave the road for a full-rust implementation of the protocol.

I must be out of the loop with this...is there still an attempt to rewrite Wayland in Rust?

Well, it's mostly a "leave the door open" thing. It's something I've been wanting to work on for some time now, and this refactor allows me to cleanly keep the possibility to do this in the future.
Basically, the idea is that as newer versions of mesa use the dmabuf extension protocol internally (rather than wl_drm), there is technically no long-term blocker to have a full rust implementation of the protocol, at least server-side (I don't know how things are regarding nvidia, but I won't make my hopes high...).
On the other hand, I want to also experiment with ideas such as "rust-implementation of the protocol with a public C api", which would allow wayland-rs to be a system-wide implementation of wayland.
So with this new refactor, the wayland-rs crates have "native_lib" cargo feature, enabled by default, which makes them use the C libs as backend. On day, I may succeed in making a native implementation, in which case removing this feature will use it. (For now, all the code will remain as unimplemented!()).
But there is not timeline nor priority for this. The core reason of this refactor is to address usability issues we encountered in smithay, and try to make the API more rust-friendly overall.

Ah ok thanks for the update.
I remember there was talk a while back about skylane being a potential implementation, but was shot down due to the mesa issues you mentioned. The fact that is unblocked is news to me, and very welcome.
I'm way too busy at the moment with Way Cooler and wlroots-rs, but maybe in the future if that is still planned / being worked on I'll look into helping out. At the very least, it will be another implementation which will be nice since everyone just uses the reference one and there should be alternatives (especially in such a safe language).

@mitchmindtree @Drakulix : Thanks for the proofreading!

Alright, this has been polished enough and I'm happy with the current state of things. Minor additional fixes shall come in new PRs an releases.


{help} HOC or Hook?

In the documentation you are talking about HOC (withTranslation) but in my code I'm using the hook (useTranslation()), it's work perfectly for now.
There is a difference or it's the same thing?
(I'm not talking about HOC vs hooks in React, but about how to use Next-i18Next for the best)

As I understand it, they have absolutely no up-to-date documentation, for example, the project is written in Typescript, and they can't document the use with TS.
At first I used HOC, but then I saw Hook and rewrote everything to hooks, as it is more convenient. I didn't notice any difference.

The withTranslation HOC and the useTranslation hook achieve the same thing. Both come from react-i18next.
@gromov-io If you feel the documentation is lacking, please open a PR.

i am lucky to search for this issue

As I understand it, they have absolutely no up-to-date documentation, for example, the project is written in Typescript, and they can't document the use with TS.
At first I used HOC, but then I saw Hook and rewrote everything to hooks, as it is more convenient. I didn't notice any difference.

I also start to change HOC to HOOK, but since when I refresh the page I'm seing a white page with loading... text in the top left of the page, am I the only one to have this difference between HOC & HOOK ?

As I understand it, they have absolutely no up-to-date documentation, for example, the project is written in Typescript, and they can't document the use with TS.
At first I used HOC, but then I saw Hook and rewrote everything to hooks, as it is more convenient. I didn't notice any difference.

I also start to change HOC to HOOK, but since when I refresh the page I'm seing a white page with loading... text in the top left of the page, am I the only one to have this difference between HOC & HOOK ?


Test: Lua Hive Partition pager

Closes #6720
This is a sunny day test to check that partitions pager works as expected.

Thanks for the review @arielshaqed ! Please look again.


Critical deadman alerts not sending notifications into slack

Steps to reproduce:
List the minimal actions needed to reproduce the behavior.

Create deadman alert for server in Influx v2.0.2 for linux metric
Set up slack notification endpoint
Create two notification rules for slack; When status changes from ANY to CRIT & when status changes from ANY to OK
Trigger deadman alert (systemctl stop telegraf)
Turn telegraf back on to clear deadman alert (reset to ok)

Expected behavior:
When telegraf switched off - Slack notification for agent offline (deadman critical)
When telegraf turned back on - Slack notification for agent online (deadman OK)
Actual behavior:
No dead man alert for CRIT sent to slack
dead man alert for OK was successfully sent to slack
Environment info:
Influx Version: InfluxDB 2.0.2 (git: 84496e507a) build_date: 2020-11-19T03:59:35Z

I confirmed this bug on Cloud 2 using the ANY to CRIT notification rule. The Alert is triggered but the notification rule is not.
It works fine with "Is equal to CRIT" and nothing else changed.

As far as I can tell, this doesn't look like a UI issue. The UI is configuring the post correctly, seems like there are some issues on the API that need to be resolved in order to get this to work

This issue will be addressed in our redesign for monitoring and alerting scheduled for Q1.

@nathleeuk can you provide more info on how your check and rule were configured. I was unable to reproduce locally with the following check and rules (using slack as the endpoint)
$ ./influx export --check-names "deadman" --rules "06bd11c26effa000,06bd1a60e97fa000"

apiVersion: influxdata.com/v2alpha1
kind: CheckDeadman
metadata:
    name: crumbling-rhodes-c3e001
spec:
    every: 1m0s
    level: CRIT
    name: deadman
    query: |-
        from(bucket: "bkt")
          |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
          |> filter(fn: (r) => r["_measurement"] == "thing")
          |> filter(fn: (r) => r["_field"] == "c")
    staleTime: 10m0s
    status: active
    statusMessageTemplate: 'Check: ${ r._check_name } is: ${ r._level }'
    timeSince: 10s
---
apiVersion: influxdata.com/v2alpha1
kind: NotificationEndpointSlack
metadata:
    name: reverent-meninsky-c3e003
spec:
    description: gregSlack
    name: deadmanSlack
    status: active
    url: https://hooks.slack.com/services/**************
---
apiVersion: influxdata.com/v2alpha1
kind: NotificationRule
metadata:
    name: pedantic-chatterjee-c3e005
spec:
    endpointName: reverent-meninsky-c3e003
    every: 1m0s
    messageTemplate: 'Notification Rule: ${ r._notification_rule_name } triggered
        by check: ${ r._check_name }: ${ r._message }'
    name: testRule
    statusRules:
      - currentLevel: CRIT
---
apiVersion: influxdata.com/v2alpha1
kind: NotificationRule
metadata:
    name: wizardly-heyrovsky-c3e007
spec:
    endpointName: reverent-meninsky-c3e003
    every: 1m0s
    messageTemplate: 'TEST2: triggered by check: ${ r._check_name }: ${ r._message
        } (ANY->CRIT)'
    name: testRule2
    statusRules:
      - currentLevel: CRIT
        previousLevel: ANY

Reproduction steps:

add data

while true; do
  curl -H "Authorization: Token ${INFLUXDB_TOKEN}" \
  "localhost:8086/api/v2/write?org=org&bucket=bkt" \
  -d 'thing,a=b c=1'; sleep 9s;
done

stop sending data after >1m, restart after >1m

I'm going ahead and closing this, as @glinton has tracked down the problem is that the UI is confusing, which, while a serious problem, is slated to be fixed. The solution, for now, is to always set your check schedule and your notification rule schedule to always exactly match.
If it turns out that there is a deeper bug, please reopen the issue. Thank you.

Apparently the reason i was unable to reproduce is because i had the check and the rule on matching schedules (1m, no offset). The only way i was able to reproduce this was by setting my rule schedule to smaller than the check schedule (check 1m, rule 10s; or check 5m, rule 1m).

As a workaround, ensure the scheduled times for your check and any associated rules match exactly.

the problem is that the UI is confusing
The ui is just fine. The check/notification implementation is unintuitive and is where the core of this flaw lives. One could create a check/notification rule directly via the api (check notification rule) or via templates and would experience equally frustrating results. The workaround applies to any method for which checks/notifications are created.

influx export --check-names "Linux Deadman" --rules "06bcbb41d1471000,06bcbb4f99071000"
apiVersion: influxdata.com/v2alpha1
kind: CheckDeadman
metadata:
name: pensive-williamson-286001
spec:
every: 1m0s
level: CRIT
name: Linux Deadman
query: |-
from(bucket: "telegraf/autogen")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "mem")
|> filter(fn: (r) => r["_field"] == "active")
staleTime: 10m0s
status: active
statusMessageTemplate: |-
Check: ${ r._check_name } is: ${ r._level }
Host: ${string(v: r.host)}.
timeSince: 1m0s
apiVersion: influxdata.com/v2alpha1
kind: NotificationEndpointSlack
metadata:
name: jolly-fermat-686001
spec:
name: Test Channel
status: active
url: https://hooks.slack.com/services/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
apiVersion: influxdata.com/v2alpha1
kind: NotificationRule
metadata:
name: clever-leavitt-686005
spec:
endpointName: jolly-fermat-686001
every: 1m0s
messageTemplate: ${ r._message }
name: Slack - Ok
statusRules:
- currentLevel: OK
previousLevel: ANY
apiVersion: influxdata.com/v2alpha1
kind: NotificationRule
metadata:
name: magical-dubinsky-686003
spec:
endpointName: jolly-fermat-686001
every: 1m0s
messageTemplate: ${ r._message }
name: Slack - Critical
statusRules:
- currentLevel: CRIT
previousLevel: ANY

Re-opening this because the same thing happens when both the check schedule and the rule schedule are set to 1m

As a workaround, it is possible to create this functionally by writing a task that performs the desired functions. There is an example here: https://gist.github.com/wolffcm/47f6fac9e2b707c32149caad7f0ecd44

I'm only guessing, but I assume there is monitor.deadman call somewhere in the code behing deadman check in InfluxDB. The problem is that if the stream is empty, the result is also empty stream and there is nothing to be sent to notification endpoints.

Deadman alerts detects no gap!
The gap is visible in the explorer:

The gap is invisible in the alert editor:

No gap - no trigger :)
Please, fix it

Also workaround by @glinton and @rickspencer3 recommendations doesn't work.

It seems the problem is in wrong data gap detection, as I mentioned above


LinuxSshProxy: support reliable uploads of large files via chunks?

We're going to be uploading a large (10.5GB) file presently to node image VMs when during the image build process.
We should consider adding a method that can handle transient network failures and be able to restart uploads in progress without having to start over from scratch.

CLOSING: Looks like SCP uploads are working just fine.


Add assign command to UG

Add assign command to UG
Edit help, list, delete, export in UG
Sort command summary
Add header in UG

Codecov Report

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

@@            Coverage Diff            @@
##             master     #140   +/-   ##
=========================================
  Coverage     68.29%   68.29%
  Complexity      548      548
=========================================
  Files            97       97
  Lines          1905     1905
  Branches        214      214
=========================================
  Hits           1301     1301
  Misses          510      510
  Partials         94       94

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 3082b8d...b17f8d1. Read the comment docs.


Metal: last member of vertex output block is always float4 in fragment shader?

Hello.
I have an issue with one shader which has a pretty big struct used to pass data from vertex to fragment shader:
layout(location = 0) in VertexData
{
    vec2 baseUv;
    flat uvec2 albdoId;
    vec3 emissiveColor;
    flat float visibility;
    flat uvec2 normalId;
    flat float dispAmount;
    flat uint materialIndex;
    flat uint needsIndividualTransform;
    flat mat2 baseUvFromNormalUv;
    vec4 wsNormal;
    vec3 wsTangent;
    vec3 wsBitangent;
    vec3 wsView;
} inoutData;

This struct gets converted to metal code in vertex shader correctly:
struct VertexData
{
    float2 baseUv;
    uint2 albdoId;
    float3 emissiveColor;
    float visibility;
    uint2 normalId;
    float dispAmount;
    uint materialIndex;
    uint needsIndividualTransform;
    float2x2 baseUvFromNormalUv;
    float4 wsNormal;
    float3 wsTangent;
    float3 wsBitangent;
    float3 wsView;
};

but fragment shader has the last component type changed to float4:
struct VertexData
{
    float2 baseUv;
    uint2 albdoId;
    float3 emissiveColor;
    float visibility;
    uint2 normalId;
    float dispAmount;
    uint materialIndex;
    uint needsIndividualTransform;
    float2x2 baseUvFromNormalUv;
    float4 wsNormal;
    float3 wsTangent;
    float3 wsBitangent;
    float4 wsView;
};

I have played a bit with this struct to find a workaround and it seems that the last member of the struct in fragment shader always* becomes type float4 after conversion to metal. E.g. I have added a dummy single float to keep wsView float3 and that's how generated metal looks like:
struct VertexData
{
    float2 baseUv;
    uint2 albdoId;
    float3 emissiveColor;
    float visibility;
    uint2 normalId;
    float dispAmount;
    uint materialIndex;
    uint needsIndividualTransform;
    float2x2 baseUvFromNormalUv;
    float4 wsNormal;
    float3 wsTangent;
    float3 wsBitangent;
    float3 wsView;
    float4 dummy;
};

Looks like a bug to me.
Thank you for the great job!

I need SPIR-V reproducers here.

@HansKristian-Work are you asking for spv bytecode? I could dump spv disassembly that MVK_DEBUG gives.

Yes, the SPIR-V bytecode.

I have dumped spv bytecode: https://drive.google.com/drive/folders/1Me6FYqc9EzEEKL_gVdf_N9Ji_n10E6NE?usp=sharing
But running spirv-cross from command line generates vertex and fragment metal shaders with perfectly matching in-out blocks. The same glsl shader code loaded by our application results in non-matching blocks.
spirv-cross version I used in CLI was Git commit: 401296d3 Timestamp: 2021-12-03T15:38:58
Vulkan SDK version we use currently is vulkan version 1.2.182

Strange. Out of the box, the MoltenVKShaderConverter tool converts those to float3 wsView; for both shaders.
I'm wondering if there is packing info (stride, etc) in the runtime shaders, that isn't appearing in your SPIR-V files above.
For both shader conversions, can you provide the MoltenVK log entries for SPIR-V, MSL and GLSL from the MoltenVK logs (using MVK_DEBUG as you mentioned), please?
For each shader conversion, from the logs, copy everything between:
[mvk-info] Converting SPIR-V:
...
End GLSL

and post them as file attachments here.

Thanks for the extra info.
Hmmm...it's still not clear what's going wrong. Conversion of the fragment shader SPIR-V by the standalone MoltenVKShaderConverter, produces the correct float3 wsView.
It likely has something to do with the interactions between the vertex stage-out and fragment stage-in assigned locations. Although they seem to align, some quirk may be overriding location 13 with a float4 type as it comes out of the vertex stage and gets sent back into the fragment stage as an input.
If so, it would be important to track that flow in your actual app. Is it possible for you to package up your app, or a reduced sample that replicates the issue, and post it for download somewhere? We'd need to be able to replace the libMoltenVK.* library with a debug version here.

Thanks.
I'll see what I can do with publishing a reporo app. It's a huge project, however, and stripping it down to a minimalistic sample will be not easy. Most likely I'll have to wait until we have it released in a couple of months first and then share here the version without workaround :/


cmake: Improve user error feedback when cmake -H$ZEPHYR_BASE is specified

Users are sometimes mistakenly invoking cmake with $ZEPHYR_BASE set as
the source directory.
This user-error can occur if the user believes that the toplevel
CMakeLists.txt file is at the root of the repo, or if the user uses
the wrong path when invoking cmake.
The error given when this user-error occurs is cryptic and undefined,
so we replace it with what should be an easy-to-understand error
message.
Signed-off-by: Sebastian Bøe<EMAIL_ADDRESS>

Codecov Report

Merging #8144 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8144      +/-   ##
==========================================
+ Coverage   64.54%   64.55%   +<.01%
==========================================
  Files         420      420
  Lines       40142    40142
  Branches     6765     6765
==========================================
+ Hits        25911    25912       +1
+ Misses      11110    11109       -1
  Partials     3121     3121

Impacted Files
Coverage Δ

samples/philosophers/src/main.c
98.43% <0%> (+1.56%)
:arrow_up:

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 7a18b08...e0677e6. Read the comment docs.


Properly align emblem image

Describe the bug
float satyamev jayate image to left so that it cannot override header and a bug in dark night mode toogle switch button

There is no such bug when I open website.

But shift emblem image a little towards left.
Check responsiveness as well.
Do changes in every page.

Can I work on this issue?

Can I work on this issue?

This issue is already assigned look for some other issues.

@royalleads15 I suggest finishing basic and simple issues first.

Sure sir


Update milestones for 2024-10

This update:

Edits and reorders midscale milestone
Updates the visualiser tool to have an actual image based on the real live visualiser

Adds debug visualiser
Adds live visualiser and clarifies that it's now two visualisers

Fixes a typo in the deployer tool document and adds references to ArgoCD/Argo Workflow (not mentioning by name til it's locked in as a solution)

Note Deployer Tool will move to 100% done this week as we finish up the automated deployment tool version of it.


Fix for 'Error occured: bad operand type for unary +: 'str', restarting in 5s.'

I fixed the error 'Error occured: bad operand type for unary +: 'str', restarting in 5s.' - it was occurred by a comma at line 92. I also added the possibility to disable LED indications and changed source for gathering pool address.

Thaniks. Cool!


The wgrep pop-up buffer cannot be selected when C-c C-e is performed on directory or project search result

What did you expect to happen?
The writable pop-up buffer of the directory or project search result should be accessible to perform modification
What actually happened?
The writable pop-up buffer of the directory or project search result is not selectable.
Describe your attempts to resolve the issue
I have tried:

SPC w j to select the bottom pop-up window;
use the mouse to click on the bottom pop-up window;

Neither of them work to let me edit the writable buffer.
There is a workaround, if I press SPC b i and select the wgrep buffer explicitly, then the buffer will be opened in full window, and I can modify the buffer there without any problem. However, when I try to use the Z Z to apply the modification and quit the buffer, only the first part will work: the changes will be applied to each candidate file successfully, but the buffer won't be closed with prompt:

Attempt to delete minibuffer or sole ordinary window

This problem happens in both ivy and vertico for me.
However, the in-file search works fine. That is to say, if I perform the C-c C-e on the SPC s s result, then the pop-up window is automatically selected and can be modified and can be closed properly with Z Z.
So it seem it only happens for project and directory search result.
Steps to reproduce

SPC p p to open some project;
SPC s p to search some query;
C-c C-e to export the search result to a wgrep buffer;
A pop-up window is brought up and cannot be selected.

System Information
https://pastebin.com/BnkJ7Vw7

I can't reproduce this in vanilla Doom, so I suspect it's a private configuration issue. Please try to reproduce this in vanilla Doom using Doom's sandbox.

You are right. It is due to my private config. The following lines causes the problem:
(require 'sublimity-scroll)
(require 'sublimity-map)
(require 'sublimity-attractive)
(sublimity-mode 0)

Sorry for the fuss.


Splunk/Splunk output support?

Wondering if you would consider adding to the roadmap support to output to Splunk w/ Splunk dashboards as an alternative to ES for those of us who heavily utilize Splunk?  I’d be willing to assist adding this support as I have time...I could also help test if/when you decide to work toward this.

Hi @NoX1De,
I think it would be great to support Splunk. Right now you could already use Logstash filters to send the data parsed to Splunk, so we would only need the dashboards themselves, if you could help out with that it would be great :D
Pretty sure this will be added to the roadmap although I don't think we have an official one right now ^^


I write a CSVDataset class inherited from CustomDataset, then add it to file (init.py ）in the folder（datasets） ,  but still don't work（AttributeError: module 'mmdet.datasets' has no attribute 'CSVDataset'）, please help.

The running environment was wrong yesterday, and now it works and achieves a good result.  useful and impressive project. thanks a lot.

@hustzwen
Hi, could you provide more information about "running environment wrong"?
Because I'm facing the same problem with you.
Thanks~

@Joker316701882  I'm facing the same problem with you.

@237014845
python(3) setup.py install

or
export PYTHONPATH=`pwd`:$PYTHONPATH

will work.

If you use python(3) setup.py develop instead of python(3) setup.py install, then you don't need to run the setup command each time you make some modifications.


Package <IP_ADDRESS> installation fails on PreInstall.vi

I tried to install the package actor_framework_2024_for_2020-<IP_ADDRESS>.vip (from Builds folder in Cleanup branch).
I saw the LabVIEW loading dialog box, looking for Stash Framework.vi

And I finally get an error:

It seems to be a known behavior: custom actions VIs cannot use sub-VIs that are not already installed by the package. So when installing actor_framework_2024_for_2020-<IP_ADDRESS>.vip, the content of the folder Install Support has not yet been copied to their destination. And cannot be loaded by PreInstall.vi.
I get the exact same behavior with LabVIEW 2023 64-bits and LabIVEW 2021 SP1 32-bits.
I suppose (not tested) that this issue will impact the exact same way the PostInstall custom action.
One suggestion could be to set content of the sub-VIs directly in Pre-Install VI (no more sub-VIs calls, lowering readability and maintenability). A more complex approach could be to create a support package, and set it as dependency of actor_framework_2024_for_2020-<IP_ADDRESS>.vip: in my understanding, dependencies are supposed to be installed before by VIPM

With the following diagram, the zip file is created as expected at package installation:

This will be fixed once my current pull requests have been processed.  The correct build will be <IP_ADDRESS> (<IP_ADDRESS> if you are looking at the main branch).


Feature: Save blocklist on disk

blockListURL ipBlockListURL load blocklists into memories directly, so it will fetch from url on each startup. Better save it on disk and compare, merge from url.

Waiting for PR https://github.com/Simple-Tracker/qBittorrent-ClientBlocker/pull/96.

Related PR has been resolved.
I think we can indeed store all the remote URL contents first to store the disk first, while logically only process the content of the disk. This should simplify the logic of URL processing and increase the user experience.


Installing NDK automatically

Right now when appropriate NDK is not installed the build will fail with
Target native_assets failed: Error: Android NDK Clang could not be found.

IIRC gradle will install ndk automatically for externalNativeBuild projects. We do the same thing in cargokit (glue used to build rust code for Flutter plugins). That results in a smoother experience compared to failing the build. I'm currently looking into reimplementing cargokit in terms of native assets and this would be a bit of a downgrade.
This does raise question whether running build should be allowed to install NDK (or other toolchains for that matter). At least for gradle/NDK nobody seems to object.
Longer term it would be nice to have an option to install toolchains as part of build. When user has rustup installed, cargokit will currently install missing toolchains and targets. But this means that build is modifying files outside of build folder (or pub cache). Which does feels a little bit iffy. It would be great if a hypothetical native_toolchain_rust could install and manage rust toolchain, possibly stored in .pub_cache so that it can get reused between project. Or maybe this could be done during pub get through a hook, but at that point we don't know the target architecture so for rust for example we'd need to install all targets, which might be an overkill.

I think the best solution would be to introduce a package native_toolchain_ndk, that in it's build.dart does the following:

Installs the NDK if it has not been installed.
Adds the install location of the NDK to its BuildOutput as metadata.

And then the package has some code in lib/

with an extension method on BuildConfig to get the NDK path from the dependency metadata

Other packages can then depend on that package, which will cause the build.dart of package:native_toolchain_ndk to be run first.
This leads to some open questions:

What version of the NDK should this package be preferring?

The latest?
Should it try to stay in sync with the latest version from Flutter so that it avoids multiple installations of the NDK?

Should it be auto-updating? Probably no, but it should probably pick the newest installation it finds on disk if there is more than one installation.
Where should the package live. Happy to you own it if you want to maintain it. So it doesn't have to be on this repo.

Target native_assets failed: Error: Android NDK Clang could not be found.

We'd need to check if that error message comes from Flutter or from the build.dart invocation.
If that error message comes from flutter, then the NDK auto-install would need to be implemented in flutter_tools instead. Let me file an issue on the flutter repo.
All of the same applies to a package native_toolchain_rust. Note that that package name is reserved currently on pub.dev, but I'm happy to give it to someone willing to own and maintain such package. 🚀

We'd need to check if that error message comes from Flutter or from the build.dart invocation.
If that error message comes from flutter, then the NDK auto-install would need to be implemented in flutter_tools instead. Let me file an issue on the flutter repo.

Okay, the error is coming from the flutter_tools, and flutter_tools policy is to not auto-install native tooling. https://github.com/flutter/flutter/issues/144530

@dcharkes, thanks for following that up. Flutter doctor currently doesn't seem to complain if NDK is not installed, possibly something to add. I generally agree with the sentiment of not installing things silently during build. Maybe something like this would make sense down the line, which could be suggested by the error message:
dart pub activate global dart_native_asset_install
dart_native_asset_install install_ndk

Or perhaps a hook on pub get so that package could verify that all native dependencies are there and if not suggest installing them.
I did some work on a proof of concept implementation of native_toolchain_rust. It's only a rough prototype right now and need quite a bit of love, but it can build macOS, iOS and android dylibs (I only tested it on macOS for now, but I wouldn't be too surprised if it worked on other platforms as well).
  final rustup = Rustup.systemRustup()!;
  final toolchain = rustup.installedToolchains().first;

  final builder = RustBuilder(
    assetId: 'package:$packageName/${packageName}_hello_rust_ffi',
    toolchain: toolchain,
    manifestPath: 'rust/Cargo.toml',
    buildConfig: buildConfig,
  );
  builder.run(output: buildOutput);

I noticed couple of things:

On android the build mode is always debug, even in release configurations
On iOS the framework name seems to be trimmed (from hello_ffi_plugin.framework to hello_ffi_plugi.framework)
On macOS the framework is added to bundle twice (as hello_ffi_pl1.framework and hello_ffi_plugi.framework).

If these are not known issues I can file them separately.
Overall this seems like a well thought approach and so far I like it a lot. cargokit holds together with a lot of ducktape and this removes pretty much all of it. I'll work on this some more and if the feedback is good I'd be interested in maintaining the package.

Thanks for giving it a spin! 🎸

I did some work on a proof of concept implementation of native_toolchain_rust.

❤  !

On android the build mode is always debug, even in release configurations

Good catch!
The error is here:
https://github.com/flutter/flutter/blob/d3c274b25540de40e17693ce6800454b5f32ecb8/packages/flutter_tools/lib/src/build_system/targets/native_assets.dart#L318
Should be a simple fix, would you mind making a PR?
Otherwise, please file an issue on the flutter repo and cc me.

On iOS the framework name seems to be trimmed (from hello_ffi_plugin.framework to hello_ffi_plugi.framework)

This is a feature, not a bug. https://github.com/flutter/flutter/blob/d3c274b25540de40e17693ce6800454b5f32ecb8/packages/flutter_tools/lib/src/isolated/native_assets/macos/native_assets_host.dart#L152-L208

On macOS the framework is added to bundle twice (as hello_ffi_pl1.framework and hello_ffi_plugi.framework).

That sounds like a bug. Please file a bug with a minimal repro on the flutter repo and cc me.

Overall this seems like a well thought approach and so far I like it a lot.

Thanks! 😄

I'll work on this some more and if the feedback is good I'd be interested in maintaining the package.

Awesome! 🚀

https://github.com/flutter/flutter/blob/d3c274b25540de40e17693ce6800454b5f32ecb8/packages/flutter_tools/lib/src/build_system/targets/native_assets.dart#L318

Sure, I'll take a look.

On iOS the framework name seems to be trimmed (from hello_ffi_plugin.framework to hello_ffi_plugi.framework)

This is a feature, not a bug. https://github.com/flutter/flutter/blob/d3c274b25540de40e17693ce6800454b5f32ecb8/packages/flutter_tools/lib/src/isolated/native_assets/macos/native_assets_host.dart#L152-L208

I don't really think this is enforced in any way. Many first party flutter plugins have frameworks with names longer than 15 characters, i.e.

GoogleDataTransport.framework (19 characters)
FirebaseAppCheckInterop.framework (23 characters)
shared_preferences_foundation.framework (29 characters)

These are just random picks from app successfully deployed to AppStore.

These are just random picks from app successfully deployed to AppStore. EDIT: Also looking at Apple frameworks they routinely have names longer than 15 characters.

cc @jmagman should we consider removing the 15 char limit?

Some additional information: As far as I can tell the 15 character limit of CFBundleName may be applied when displaying bundle name in places with limited spaces. But that only applies for app bundles, it doesn't seem to be relevant for frameworks.

cc @jmagman should we consider removing the 15 char limit?

Thanks for the research, @knopp.  Let's take the char limit out. If there's actually a problem with App Store submission I'm sure we'll hear about it.

@knopp If you would like to make a PR, the corresponding tests are in packages/flutter_tools/test/integration.shard/native_assets_test.dart. Otherwise, I can take a look tomorrow.


possibility to add target directory for automatic setup

Hello,
is there any possibility to setup target directories for the automatic installation?
I tried to set settings.txt in the current directory of nvm-setup.exe.
I also tried to setup NVM_HOME and NVM_SYMLINK (even NODE_PATH). Through .bat file, for user and for machine (SETX /M ..), I validated that the environment variables are set, but still the setup is not using them.
And in the wizard, I see the default values.
Please let me know, thank you

This isn't possible in the current installer. The current installer defines these variables, so it will temporarily overwrite anything you set.

Ok, I see. Would it be possible to add some configuration/command line parameters for the installer, so that we could redefine those values, please?
What we are trying to achieve is to create semi-automatic installer of our project, that will put everything (nvm win, nodejs, our sw) in one parent folder, so it is easier for later introspections/suport/uninstallation. For that we need to redefine the default values in the installer, so the people, who will be installing it, won't need to change the folders manually (browse) (potential source of mistakes :))
Please, let me know, or if you can point me to the proper direction/source file/lines, I can add it on my own.
Thank you

@miira There will be a Chocolatey package wrapping the nvm-nosetup.zip coming soon that will allow you to modify these things in the next version or two of it's life.
I may also see about trying to make a more generic PowerShell script if you can't/won't use Chocolatey to install the zip file and set the various pieces up, but really Chocolatey is an awesome way to go.

Closing due to age and alternative options (chocolatey).


Add MDP policy gradient

@fabikonsti I fixed the typehints and updated to py3.8, now the pipeline runs through. You can merge this branch into yours again, or we merge this one, whatever you prefer

#14 was merged instead


Per server prefixes

Hi
I was trying to setup per server prefixes. I did this:
/lp group snul meta addprefix 100 &8(&r&eSnul&r&8)&7 server=harrypotter
I changed the server name in the config to harry potter and /lp user Christophe6 returns that I have the right prefix. But when I use essentialschat and vault, it returns just Member... How can I solve this?

But when I use essentialschat and vault, it returns just Member

Use EssentialsXChat, not essentialschat
The "Member" is a config setting in Essentials - not to do with Luckperms.  Check your Essentials config.

I am using essentialsxchat. The permissions do perfectly work for global ranks...

Are you sure your prefixes are being pulled from LP, and not just the Essentials config file?
What is use-vault-server set to in your LP config?


Scroll on body doesnt work when using blur

The body doesn't scroll when using the blur effect. Guess this is because a backdrop widget is not really removed when the panel is closed. The opacity is just reduced.

Hi @devoluwatobi 👋
I will try to reproduce this issue as soon as possible and fix this issue.


FR15: Explain Key Programming Concepts

FR15: Explain Key Programming Concepts

Goal: Ducki should explain concepts according to the user's level of experience.
Stakeholders: Computer Science Students
Description: When prompted to explain a concept, Ducki will provide an understandable explanation tailored to the user's experience level.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/14/2024
Priority: 3

Through various prompt tests, we have determined that Ducki is providing adequate responses and is able to explain programming concepts in a comprehensive way


FIX kit2fiff-GUI:  allow converting files with unknown format

Fixes #4634 for the GUI. I was trying to help someone convert old data today and found what the issue was (the raw file is read twice, and the allow_unkown_format parameter was omitted the second time). Bad timing. Can this go into a minor release or should I ask them to install the dev version?

Appveyor failed due to time-out. Should I be able to restart? Can't see a button even after logging in.

Restarted and invited you to have permissions on AppVeyor

(IMO it can go in a minor release but we usually wait a couple of weeks for bug reports to trickle in)

Thanks! I can help them install from master for now.

Thanks @massich !


V4 Aggregate Calculation

Hi,
I updated to 4.0 and am having a problem with the aggregate calculation. The page gets stuck on the 'LOADING...' and never completes calculating. There is an 'undefined method' error which is preventing the calculation from completing. Please see the attached screenshots.
-Nick

Taking a look, this is my fault.  I broke it in #49 - I missed that aggregate_result is still used.  We can revert that PR, and I'll work on a fix so that the new version of bundler will work.

@npm526 could you see if PR #57 fixes the issue for you?

@lrasmus yes, this fixed the issue that I was seeing. Thank you!


Skip flatten.each in HTTP to_json_stream

Process each scanned element from chunk without intermediate array created by scan, flattened and iterated again.
All Submissions:

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?

Thanks @Maumagnaguagno - this seems to work but I can't find the Ruby docs for the mechanism here, can you explain this a bit / link to them? Thank you!

String#scan without a block returns an arrays of match arrays, even if there is a single capturing group/matched element.
The Array#flatten is currently used to remove the array around the matched element.
By passing block to String#scan with |data,| we can splat the matched array just like flatten, keeping only data as the first element, without the intermediate arrays created by scan and flatten.
Another solution is to avoid the capturing group and prefer a lookbehind regex.

Using the new event_stream_parser for this. Thanks anyway for this contribution!


Use windows-2019 image in CI

As you can see in a recent Azure Pipelines build, the Windows Server 2016 image is now deprecated: https://dev.azure.com/miurahr/github/_build/results?buildId=4687&view=logs&j=c4497b2b-649a-591e-539b-0d716883e33e
The newer vmImage: 'windows-2022' would work too; see https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml

https://dev.azure.com/miurahr/github/_build/results?buildId=4688&view=logs&j=a846d25a-e32c-5640-1b53-e815fab94407&t=e95a39fa-5cd2-5eb3-7a94-1fe6d1d1b7b0&l=17:
FullyQualifiedErrorId : No instances of Visual Studio 2017 found.

Looks like all the Windows BuildJob architectures will need to be updated to 2019. Not as simple as I had hoped.

I'd like to squash and merge it.

I'd like to squash and merge it.

Ok, it's squashed.


refine readme

变更内容

添加英文readme

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


Should the following sentence be in a cell?

https://github.com/johnwparent/APBPoster/blame/master/wrapper_yaml.rst#L104

No, that's where I intended it to be. This is the same as the APB readme. Do you think it should be moved elsewhere?

No looking at it again its fine. I might just restructure the sentence a bit.


Please invite me to the community

Name
Larry
Additional Context
I'd like to join this community.

Invitation sent to join the GitHub Organization. Welcome to Infraform 🎉Please check your mail to accept the invitation sent by GitHub! 🤖About usInfraform is a remarkable open-source solution tailored for serverless platforms, aimed at empowering creators to craft their infrastructure solutions. 💻 We're thrilled to welcome you into our vibrant community! ✨ We eagerly anticipate your valuable contributions! 🤓 Don't forget to explore our community on Github and connect with us on LinkedIn 💜 Feel free to spread the word about our community to like-minded individuals interested in development, DevOps, technology, and collaborative contributions. 👉💜👈


Update alert.yml

Updating alert.yml with new launch information
Description
Corrects the banner data to align with 1.0 launch.
Issues Resolved
"OpenSearch RC1" -> "OpenSearch 1.0"
"June 7th! -> "July 12th!"
By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

I'm fine with this to keep everything correct, but I think we need to switch it up and only keep up a single alert for a fixed amount of time. I'm not sure anyone will notice it's changed!
Maybe later in the week we can switch it up a bit.


Can't save anndata after running define_clonotypes

reported by @chris-rands in #243:

I can't save the object to .h5ad due to TypeError: Can't implicitly convert non-string objects to strings with Above error raised while writing key 'uns/clonotype/cell_indices' of <class 'h5py._hl.files.File'> from /. I encountered this with parts of scanpy also, e.g. theislab/scanpy#1651 (comment)

This issue only appears with h5py >= 3.
See also https://github.com/theislab/anndata/issues/493


BUG: timeout argument / kwarg passthrough

At a glance, should the timeout parameter pass through to client.request / http.request in kwargs?

Note: I have no idea how to test this.


Doesn't stretch slides to 100% height

Doesn't stretch slides to 100% height.
The fix is:

Reset this CSS rule.

.swiper-slide {
  height: 100%
}

via
.swiper-slide {
  height: auto
}

Stretch the slides via flexbox

.swiper-wrapper {
  align-items: stretch
}

In the current version, that doesn't fix it for me .. :(

If anyone else still encounters the issue despite this solution: don't forget to add "width: 100%" or h-full if you are on Tailwind to swiper-slide's child component after setting swiper-slide's height to "auto". You also may not need of align-items stretch. Tested on Remix 1.19.1/React 18.2.0 and Swiper 11.1.4.

If anyone else still encounters the issue despite this solution: don't forget to add "width: 100%" or h-full if you are on Tailwind to swiper-slide's child component after setting swiper-slide's height to "auto". You also may not need of align-items stretch. Tested on Remix 1.19.1/React 18.2.0 and Swiper 11.1.4.

Thanks bro, i tried with mine and worked perfectly, but i have to put ! before h-auto because it wasn't prioritized in the first:

If anyone else still encounters the issue despite this solution: don't forget to add "width: 100%" or h-full if you are on Tailwind to swiper-slide's child component after setting swiper-slide's height to "auto". You also may not need of align-items stretch. Tested on Remix 1.19.1/React 18.2.0 and Swiper 11.1.4.

This deserves a medal of honor!


Does it support merging multiple pptx files into one?

Hi,
Thanks for the great tool. I don't see functions for merging multiple pptx files in this lib, does it not have this feature or I missed it?
Thanks,
Michael

Hi @leavedream
No, merging pptx files is not a feature of the library.


handleresultif and fallback with exception -- possible?

In a testing scenario, some REST endpoint sporadically returns a non-200 status.
In case that it eventually returns a 200, then the test should continue.
In case that it keeps returning a non-200, then the test should fail with some exception.
Tried the following:
        try {
            Failsafe.with(
                new RetryPolicy<Integer>()
                    .withMaxRetries(3)
                    .handleResultIf(result -> result == 0)
                    .onRetry(event -> log.info("Retrying...")),
                // does not work :(
                Fallback.of(() -> { throw new SOME_EXCEPTION(); }))
                .get(() -> 0);

            fail("an exception should have been thrown");
        } catch (final RuntimeException t) {
            log.info("failed with {}", t.toString());
        }

also tried:
(Policy<Integer>) execution -> {
                    throw new NullPointerException();
                }

instead of the Fallback, but then no retries occur :(
Any suggestions?

Several things here:

You have the RetryPolicy wrapped around the Fallback, but you want it the other way around: The fallback should do its thing only if the retries are exhausted.
You want the fallback to throw an exception rather than return one, so you need ofException  or builderOfException.
You want both the fallback and the retry policy to have the same understanding of what failure is.

With that in mind, here's a unit test that shows both success and failure:
    Fallback<Integer> FALLBACK =
        Fallback.<Integer>builderOfException(e -> new RuntimeException("req fail"))
            .handleResultIf(this::badStatus)
            .build();

    RetryPolicy<Integer> RETRY =
        RetryPolicy.<Integer>builder()
            .withMaxRetries(3)
            .handleResultIf(this::badStatus)
            .onFailedAttempt(e ->
                System.out.printf("Attempt #%d failed%n", e.getAttemptCount()))
            .build();

    FailsafeExecutor<Integer> EXEC =
        Failsafe.with(FALLBACK).compose(RETRY);

    @Test
    public void successfulCase() {
        int result = runWithStatuses(new int[] { 404, 200 });
        assertEquals(200, result);
    }

    @Test(expected = RuntimeException.class)
    public void unsuccessfulCase() {
        runWithStatuses(new int[] { 404, 404, 404, 404 });
        fail("should have failed");
    }

    int runWithStatuses(int[] statuses) {
        AtomicInteger i = new AtomicInteger(0);
        return (int) EXEC.get(() -> statuses[i.getAndIncrement()]);
    }

    boolean badStatus(int status) {
        return status != 200;
    }

Note the use of the badStatus method to make it clear that the fallback and retry policy have the same notion of what kinds of situations should be handled.
And note the use of compose to make it clear which policy is outermost.

@Tembrel's response is spot on. The only thing I'd add is a few links to docs that describe some of the things he mentioned:

Each policy determines whether a result/exception is a failure: https://failsafe.dev/policies/#failure-handling
Order matters when composing policies: https://failsafe.dev/policies/#policy-composition

Thanks for the detailed explanation :)
Since I am still with version 2.x.x, here is the complete working configuration:
Failsafe.with(
                Fallback
                    .<Integer> ofException(
                        e -> new RuntimeException(e.getLastResult().toString()))
                    .handleResultIf(result -> result == 0),
                new RetryPolicy<Integer>()
                    .withMaxRetries(3)
                    .handleResultIf(result -> result == 0)
                    .onRetry(event -> log.info("Retrying...")))

BTW... Is it possible somehow to git rid of the duplicate .handleResultIf(result -> result == 0) ?

BTW... Is it possible somehow to git rid of the duplicate .handleResultIf(result -> result == 0) ?

Not if you want the RetryPolicy and the Fallback to share the same notion of what constitutes a "bad" result, and you very much do, in this case.
I think a best practice here (illustrated above as well) is to encapsulate that predicate with a suggestively named method in the class where the policies are defined. Then you can make the duplication explicit:
Fallback fb = Fallback.builder(...)
    .handleResultIf(this::isBadResult)
    .build();

RetryPolicy rp = RetryPolicy.builder()
    .handleResultIf(this::isBadResult)
    .build();

This explicit repetitiveness might seem onerous, but consider that there are situations where different policies in a composition need different handling. For example, a retry policy that exceeds its limits returns the result or exception from its last attempt. In a slightly different setting from the one you describe, it might be desirable to return the last result, e.g., a non-200 status code, but still provide a fallback for a particular exception:
Fallback<Integer> fb = Fallback.<Integer>builder(504)
    .handle(NetworkException.class)
    .build();

RetryPolicy<Integer> rp = RetryPolicy.<Integer>builder()
    .withMaxAttempts(MAX_ATTEMPTS)
    .handleResultIf(this::isBadStatusCode)
    .build();

FailsafeExecutor<Integer> exec = Failsafe.with(fb).compose(rp);

Note that handleResultIf doesn't remove the default handling for exceptions.
The FailsafeExecutor defined here will return the result of the first attempt that doesn't have a bad status code or the last result if all the attempts have bad status codes. If a NetworkException is thrown as the last attempt, the fallback intercepts it and replaces it with a 504 result. Otherwise, an exception thrown on the last attempt is propagated and ultimately thrown wrapped by a FailsafeException.
Here's a gist that tests that code.

Closing for now. Feel free to re-open if the above didn't answer your question.


Start three times by loop, It can not work

For each loop, I have close it. But it can work after two times.

For each loop, I have close it. But it can not work after two times.

Thanks for your reply.
Yes. I have stop it for each loop. Is there any limitation for times？
I do this because I need to capture picture by proxy for a login page. I need use proxy each time for diffrent user。
---Original---
From: @.>
Date: Tue, Mar 22, 2022 22:05 PM
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [justcoding121/titanium-web-proxy] Start three times by loop, Itcan not work (Issue #908)
Why do you do this? Only for testing? Do you stop it properly in the loop?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

https://github.com/BurningTeng/NeusoftSign/tree/v2.0。
I have write code like below:
             for (var i =0 ;i < 10; i++) {       var task = Task.Run(() =>         {             su.StartProxyServer();             su.SetProxyPort();             su.Sign(listPerson[0].name, listPerson[0].email, listPerson[0].password);         }) } ;
For each loop. I close Proxy at Sign function. But when I tries three times, Proxy is error

but you execute them parallel.... you can't do that.

The output is wrong when use diffrent port. You can test code via https://github.com/BurningTeng/NeusoftSign/tree/tmp.
Main code as below:
SignProxy signProxy = new();

signProxy.StartProxyServer();
signProxy.SetProxyPort(8888);
SignUtils.Sign();
signProxy.StopProxyServer();

await Task.Delay(10000);

signProxy.StartProxyServer();
signProxy.SetProxyPort(9999);
SignUtils.Sign();
signProxy.StopProxyServer();

Sign function as below:
  public static void Sign()
  {
      /*            IWebDriver wd = new OpenQA.Selenium.Edge.EdgeDriver();
                  wd.Quit();*/
      Console.WriteLine("Doing a request");
      Console.WriteLine(HttpClient.DefaultProxy.GetProxy(new Uri("http://localhost")));

  }

For 9999 port, the output is wrong. I except the output should be http://localhost:9999/ other than 8888.
Listening on 'ExplicitProxyEndPoint' endpoint at Ip <IP_ADDRESS> and port: 8888
Set endpoint at Ip <IP_ADDRESS> and port: 8888 as System HTTP Proxy
Set endpoint at Ip <IP_ADDRESS> and port: 8888 as System HTTPS Proxy
Doing a request
http://localhost:8888/
Listening on 'ExplicitProxyEndPoint' endpoint at Ip <IP_ADDRESS> and port: 9999
Set endpoint at Ip <IP_ADDRESS> and port: 9999 as System HTTP Proxy
Set endpoint at Ip <IP_ADDRESS> and port: 9999 as System HTTPS Proxy
Doing a request
http://localhost:8888/


Support fstart and fend when edit_in/edit_out are not present.

we've made some decisions today on supported attributes and cleaning up the whole problem of using different attributes in different places, but this is a good hotfix for now.


Fix typo in budget-api.md

CLA: Jarrod Mosen

Hey @wub - thanks for the contribution. I'm going to close this PR since it doesn't fix any major issues that we tend to look for.

Apologies @wub! I hadn't finished my morning caffeine yesterday when I reviewed this. Thanks for your contributions and for pointing out my oops!


Create initial wasm.print module

Create a new wasm.print similar to llvm.print.
Let's come up initial API that is enough to create printBoolean function.
Please post the planed public API here before implementing (Maybe start with a sample unit test).

https://github.com/poorna2152/nballerina/pull/4

https://github.com/poorna2152/nballerina/pull/7

Initial Module function implementation:  https://github.com/poorna2152/nballerina/pull/8


Viewing Activity Logs?

Hi, just curious what you guys recommend for viewing the saved activity logs.
Is there a frontend web page to easily view logs recorded with this package?
Thanks.

Because of the different possibilities to use this package we don't provide any view. The simplest solution would be a simple blade view where you loop @foreach() over your activities related to a single model, type, channel or all and render any kind of table, list or whatever you need.
In more advanced solutions you can use something like list.js, dataTable.js or any SPA approach to load the activities with an async request, add filter/Search options and render only the matching ones.

Ok, np, I thought so.  Thanks!


helm template not creating as helm install

deployment file
{{- $replicaCount := .Values.replicaCount | int }}
{{- range $i, $e := until  $replicaCount  -}}
{{- $name := printf "app%02d" (add $e 1) }}
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ $name }}
spec:
replicas: 1
selector:
matchLabels:
app: {{ $name }}
template:
metadata:
labels:
app: {{ $name }}
spec:
containers:
- name: {{ $name }}
image: nginx
{{- end }}

values.yaml
replicaCount: 4

expected output: creating 4 deployment files with name app01, app02,app03,app04
output:  creating only deployment file with app04.

helm template value
Source: app/templates/depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app01
spec:
replicas: 1
selector:
matchLabels:
app: app01
template:
metadata:
labels:
app: app01
spec:
containers:
- name: app01
image: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: app02
spec:
replicas: 1
selector:
matchLabels:
app: app02
template:
metadata:
labels:
app: app02
spec:
containers:
- name: app02
image: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: app03
spec:
replicas: 1
selector:
matchLabels:
app: app03
template:
metadata:
labels:
app: app03
spec:
containers:
- name: app03
image: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: app04
spec:
replicas: 1
selector:
matchLabels:
app: app04
template:
metadata:
labels:
app: app04
spec:
containers:
- name: app04
image: nginx
helm output with debug
helm upgrade --install app app/ -n app --debug
history.go:56: [debug] getting history for release app
upgrade.go:142: [debug] preparing upgrade for app
upgrade.go:150: [debug] performing update for app
upgrade.go:322: [debug] creating upgraded release for app
client.go:229: [debug] checking 1 resources for changes
client.go:512: [debug] Looks like there are no changes for Deployment "app04"
upgrade.go:157: [debug] updating status for upgraded release for app
Release "app" has been upgraded. Happy Helming!
NAME: app
LAST DEPLOYED: Tue Aug  6 08:57:47 2024
NAMESPACE: app
STATUS: deployed
REVISION: 4
TEST SUITE: None
USER-SUPPLIED VALUES:
{}
COMPUTED VALUES:
replicaCount: 4
HOOKS:
MANIFEST:
--- Source: app/templates/depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app01
spec:
replicas: 1
selector:
matchLabels:
app: app01
template:
metadata:
labels:
app: app01
spec:
containers:
- name: app01
image: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: app02
spec:
replicas: 1
selector:
matchLabels:
app: app02
template:
metadata:
labels:
app: app02
spec:
containers:
- name: app02
image: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: app03
spec:
replicas: 1
selector:
matchLabels:
app: app03
template:
metadata:
labels:
app: app03
spec:
containers:
- name: app03
image: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: app04
spec:
replicas: 1
selector:
matchLabels:
app: app04
template:
metadata:
labels:
app: app04
spec:
containers:
- name: app04
image: nginx

Output of helm version:
version.BuildInfo{Version:"v3.14.3", GitCommit:"f03cc04caaa8f6d7c3e67cf918929150cf6f3f12", GitTreeState:"clean", GoVersion:"go1.21.7"}
Output of kubectl version: v1.30.3
Cloud Provider/Platform (AKS, GKE, Minikube etc.):  onprem

Add --- under the range statement.


Extrinsic pool benchmarks

closed via https://github.com/paritytech/substrate/pull/3922 (re-open otherwise)


Credentials switch doesn't accept empty credentials objects

Unlike most Cmdlets that take a credentials parameter, get-windowsfeatures doesn't accept empty credentials variables.
So calling get-windowsfeatures from within a function that takes a credentials variable defined as follows throws an error if no credentials are supplied to the calling function.
[ValidateNotNull()]
[System.Management.Automation.PSCredential]
[System.Management.Automation.Credential()]
$Credential = [System.Management.Automation.PSCredential]::Empty
Calling Get-WinEvents, Get-WmiObject etc with an empty credentials value works normally, but get-windowsfeature fails with "Get-WindowsFeature : Object reference not set to an instance of an object."

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

ID: b8b3d536-027d-e21d-f160-42c2c2d02191
Version Independent ID: 1408677c-e0ff-aaad-f84e-d97351461a62
Content: Get-WindowsFeature (servermanager)
Content Source: docset/winserver2012r2-ps/servermanager/Get-WindowsFeature.md
Product: powershell
GitHub Login: @brianlic
Microsoft Alias: brianlic

@ChrisParrBIE
Note that the form that you have submitted this feedback from is intended for product documentation issues only.
Please consider checking any relevant resources and asking the community about your problem via the following link.
PowerShell Community
Thanks.

@officedocsbot close


Zs singlestatstring #15314

Closes #15314
Describe your proposed changes here.

[ ] CHANGELOG.md updated with a link to the PR (not the Issue)
[ ] Well-formatted commit messages
[ ] Rebased/mergeable
[ ] Tests pass
[ ] http/swagger.yml updated (if modified Go structs or API)
[ ] Documentation updated or issue created (provide link to issue/pr)
[ ] Signed CLA (if not already signed)

Looks good.


Unable to reach the REST server: ERR_CONNECTION_REFUSED

I followed the instructions on https://ibm-blockchain.github.io/interacting/.
bx cs workers blockchain : lists Card  PeerAdmin@hlfv1
businessNetworkName is empty
$ composer card list --card PeerAdmin@hlfv1
userName:            PeerAdmin
description:
businessNetworkName:
identityId:          114aab0e76bf0c78308f89efc4b8c9423e31568da0c340ca187a9b17aa9a4457
roles:
  - PeerAdmin
  - ChannelAdmin
connectionProfile:
  name:    hlfv1
  channel: composerchannel
credentials:         Credentials set

Created 2nd card:
./create/create_composer-rest-server.sh --business-network-card perishable-network
...
Composer rest server created successfully

Pinging the 1st card:
$  composer network ping -c PeerAdmin@hlfv1
Using default API endpoint: {{.Endpoint}}
OK
OK
ID                                                 Public IP         Private IP      Machine Type   State    Status   Zone    Version
kube-mil01-paa873e781feac4583a788cc62033f1732-w1   <IP_ADDRESS>   <IP_ADDRESS>   free           normal   Ready    mil01   1.10.5_1519
MacBook-Pro-3:scripts jps$  composer network ping -c PeerAdmin@hlfv1
Error: No connection type provided, probably because the connection profile has no 'x-type' property defined.
Command failed

Pinging the 2nd card:
$  composer network ping -c admin@perishable-network
Error: Card not found: admin@perishable-network
Command failed

bx cs workers blockchain : lists Card PeerAdmin@hlfv1 only
composer card list: only PeerAdmin@hlfv1
http://<IP_ADDRESS>:31090/explorer/: ERR_CONNECTION_REFUSED
Maybe I used a wrong business network ID  perishable-network?

In the step
cd cs-offerings/scripts/
 ./create/create_composer-rest-server.sh --business-network-card INSERT_BIZCARD_NAME

The business network card name should be
admin@perishable-network
So the command looks like
cd cs-offerings/scripts/
 ./create/create_composer-rest-server.sh --business-network-card admin@perishable-network

You need to delete the rest server pod first by doing
./delete/delete_composer-rest-server.sh

and recreate the rest server

thx, running ok now


[youtube] Music search

Checklist

[X] I'm reporting a site feature request
[X] I've verified that I'm running yt-dlp version 2022.01.21. (update instructions)
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[ ] I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Example URLs
https://music.youtube.com/search?q=royalty+free+music
Description
music.youtube gives different search results than normal search.
We already have all the code to make the necessary requests. Only the code for traversing the response needs to be written
Related: https://github.com/yt-dlp/yt-dlp/issues/622

@coletdjnz in case u r interested


[bug] yarn tauri dev crashes with "panicked at 'called Result::unwrap() on an Err value"

Describe the bug
Running $ yarn tauri dev throws a Rust error (see stack trace).
Reproduction

$ yarn create tauri-app with the following options:

Package manager: yarn
UI template: react-ts

Follow instructions:

$ yarn
$ yarn tauri dev

$ yarn tauri dev results in:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/interface/rust.rs:762:69

Expected behavior
It should not crash.
Platform and versions
$ yarn tauri info
yarn run v1.22.18
$ tauri info

Environment
  › OS: Mac OS 12.6.0 X64
  › Node.js: 18.8.0
  › npm: 9.1.3
  › pnpm: Not installed!
  › yarn: 1.22.18
  › rustup: 1.25.1
  › rustc: 1.65.0
  › cargo: 1.65.0
  › Rust toolchain: stable-aarch64-apple-darwin

Packages
  › @tauri-apps/cli [NPM]: 1.2.2
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.2,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.7,
  › wry [RUST]: 0.23.3,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../dist
  › devPath: http://localhost:1420/
  › framework: React
  › bundler: Vite

App directory structure
  ├─ dist
  ├─ node_modules
  ├─ public
  ├─ src-tauri
  ├─ .vscode
  └─ src
✨  Done in 8.53s.

Stack trace
$ export RUST_BACKTRACE=full; yarn tauri dev
yarn run v1.22.18
$ tauri dev
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/interface/rust.rs:762:69
stack backtrace:
   0:        0x10896c368 - _napi_register_module_v1
   1:        0x108588b1c - <unknown>
   2:        0x10894681c - _napi_register_module_v1
   3:        0x108970ae4 - _napi_register_module_v1
   4:        0x1089707a8 - _napi_register_module_v1
   5:        0x108970ea8 - _napi_register_module_v1
   6:        0x108970de0 - _napi_register_module_v1
   7:        0x108970d54 - _napi_register_module_v1
   8:        0x108970d30 - _napi_register_module_v1
   9:        0x108cdc158 - _napi_register_module_v1
  10:        0x108cdc310 - _napi_register_module_v1
  11:        0x108a81b7c - _napi_register_module_v1
  12:        0x108b77a9c - _napi_register_module_v1
  13:        0x108bd499c - _napi_register_module_v1
  14:        0x108bdb510 - _napi_register_module_v1
  15:        0x108bda82c - _napi_register_module_v1
  16:        0x108972eb4 - _napi_register_module_v1
  17:        0x19de0426c - __pthread_deallocate
✨  Done in 1.12s.

Additional context
I worked around this by running cargo build in src-tauri/. yarn tauri dev works after that.
This appears to be some CLI tooling issue. The error is thrown from this block, specifically L762:
https://github.com/tauri-apps/tauri/blob/eaf0d71779707c69903aba6106322c8908107242/tooling/cli/src/interface/rust.rs#L762

Did you install Rust?

..turns out it was an issue with my $PATH - I was in an old session and forgot to re-source after moving some things around.
Thanks @amrbashir!


Switch is prone to remounts

See the various issues people have with Switch and keys on Routes causing unintended remounts, like https://github.com/ReactTraining/react-router/issues/4578#issuecomment-325859968
How about adding an optional prop on Switch, routes, which is an array of the Route props? If it is there, children would be ignored and it would be Switch that makes the <Route {...chosenProps}/> without having to clone the child.
So instead of
<Switch>
  <Route path="foo" component={Foo} />
  <Route path="bar" component={Bar} />
  <Route path="bar2" component={Bar} />
  <Redirect to="foo" />
</Switch>

we'd have
<Switch
  routes={[
    {path:"foo", component: Foo},
    {path:"bar", component: Bar},
    {path:"bar2", component: Bar},
    {redirectTo: "foo"},
  ]}
/>

That's just what react-router-config does. So, it already exists.

I agree this is a problem, but I'd like to solve this with components. I'd hate to have 2 ways for people to define routes.

We also have tests and a fix in place in #4592. I'm not sure why this would be happening...

:+1: all makes sense, closing…


Add GPU info to like_top.py

For my own purposes, I modified like_top to report GPU usage. Could be added in, but needs better handling of multiple GPUs, and if it's a CPU-only build.
Here's the code gist:
def _getGpuMemoryUsage():
    """ Grab nvidia-smi output and return a dictionary of the memory usage. """
    q_flag   = '--query-gpu=memory.used,memory.total,memory.free,power.draw,power.limit'
    fmt_flag = '--format=csv,noheader,nounits'
    p = Popen(['nvidia-smi', '-i', '0', q_flag, fmt_flag],
                   stdin=PIPE, stdout=PIPE, stderr=PIPE)
    output, err = p.communicate()
    # Parse the line and turn them all into integers
    output = map(int, map(float, output.strip().split(',')))
    data_label = ['memUsed', 'memTotal', 'memFree', 'powerDraw', 'powerLimit']
    data = dict(zip(data_label, output))
    return data

And then in the display loop:
gpu  = _getGpuMemoryUsage()
...
### GPU memory usage
output  = 'GPU:  %8iMi total, %8iMi used, %8iMi free' % (gpu['memTotal'], gpu['memUsed'], gpu['memFree'])
output += '   Power:  %i/%i W\n' % (gpu['powerDraw'], gpu['powerLimit'])
k = _addLine(scr, k, 0, output, std)

And then you get this extra line:

That's a cool idea.  It would also be good if we could add in GPU utilization somehow.  I think nvidia-smi only supports that for computing cards but maybe there is a way to get around it.  Is power usage a good proxy of utilization?

Oh, it looks like the gaming cards don't provide the power draw through nvidia-smi.

I made a few changes to like_top.py to address this in 1e61eda.  It should be able to handle CPU-only builds and the limited nvidia-smi information you get on some cards.


(docs)(PUP-6739) Expand environment setting doc.

See puppet-docs PR #816
by @melissa.
This commit expands the information provided for just how environment is
used when defined in puppet.conf. This variable has different
implications when defined in different contexts. Prior to this commit,
we simply had a very vague description of how it is used, with no
explicit detail about what happens if the user sets environment in the
different sections of puppet.conf. This commits adds in some of that
detail that was previously lacking.

Content in this PR was reviewed by @MikaelSmith in puppet-docs PR #816.
CC @melissa

CLA signed by all contributors.

What's needed to get this merged in? Do we just need to bother someone to hit the button?

@joshcooper Does this need to be manually cherry-picked forward to 5?

@gguillotte it turned out I messed up the merge to 5.3.x and up. That's been fixed, so no additional actions are needed.


Receiving Error: Unable to process command '::set-env

I am recieving the below error when running the task on ubuntu-latest. I see core 1.2.6 is already updated in package-lock.json.
    - name: Get KeyVault Secrets
      uses<EMAIL_ADDRESS>      with:
        keyvault: "mykv"
        secrets: 'ARM-CLIENT-ID, ARM-CLIENT-SECRET, ARM-SUBSCRIPTION-ID, ARM-TENANT-ID'
      id: get_secret_action

Error: Unable to process command '::set-env name=AZURE_HTTP_USER_AGENT,::GITHUBACTIONS_GetKeyVaultSecrets_**' successfully.
Error: The `set-env` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

I believe this is the same issue as #15. Even though core 1.2.6 has been updated, according to #15 an updated node_modules has to be pushed along with the release, which hasn't happened yet.

I have made the required changes. Please test at your end and let us know if you face any difficulty.

Working for me.

@romil07 working now, thanks

@romil07 still getting the same error off of latest version. I see latest version is still<EMAIL_ADDRESS>

@jontreynes , I think you use @v1.1. Please, change to :
uses: Azure/get-keyvault-secrets@v1

Hi @artsheiko
Just to confirm that I've updated v1.0 to v1 and I no longer get such errors:

How come that v1.0 and v1.1 is older than v1? This is very confusing and took me a while to figure out. Why is v1 not called v2 or v1.2 for that matter?

@artsheiko thanks and confirming @v1 works


Create / Retrieve / Update / Delete apiKey for any user

The documentation it not super clear but it appears that the API key resource is only available for the user that's been configured as part of the provider {}.
We would like to be able create/update/delete api_key resources for users. Either specifying the user as a parameter to api_key resource, or creating an api_key for each artifactory_user resource.  Both would be ideal for flexibility.
We tried to create an instance of provider {} for reach artifactory_user we manage, so as to retrieve the apiKey, but it does not seem obvious how to do so.

@evilensky, the provider uses the Artifactory REST API on the backend. The current Artifactory API implementation allows generating a new API key only for the current user.
Admin user can revoke an API key for another user. But this is the only operation, that can be performed on the other user by the admin. So, the admin can't generate an API key for a user.
API key can't be created at the same time as a user, per [API documentation] (https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-CreateorReplaceUser) either.
Looks like all we can do is to generate an API key for the current user, whose credentials are used in the provider {}
@chb0github what do you think?

You can only generate an API per user and there is a security reason why:
Imagine if user A could Generate a key for user B - User A could use key for user B and impersonate him.
This isn't possible - by design


Pb at jsonify in return from Class

Hi,
I have successfully (almost, I guess) manage to build a start of api.
Unfortunately when I wrap my function into a class I guess an error message. I cannot find explanation for that.
Works fine:
from flask import Flask, jsonify, request, url_for, abort
from flask import make_response
from tuto import app
from tuto.app import db
from tuto.api import bp
from tuto import models
from tuto.models import Entreprise, Offre, User, Candidate
from flask_restx import Resource, Api, fields
app = Flask(name)
message = {}

When I wrap it as a method of a class:, I have message:
The view function did not return a valid response. The return type must be a string, dict, tuple, Response instance, or WSGI callable, but it was a Candidates.

Thanks

Well, it looks like you are using your own approach to building the API, not the approach described in my tutorial. So I really don't know, you must be doing something that is incorrect, but I don't really know what that is. Check the documentation of the package from where you imported the Resource class to see how they recommend you build your API.


Update genetics-app dependencies

There are 3 PRs open from dependabot with security updates.
For the v6 release, can we please update all dependencies for genetics-app?

Ticket closed as work completed and merged into v6 release


Fixes get_token integrator key parameter

Discovered the bad parameter name when we went to create our first oauth tokens.  This is returning successfully for me now.

:+1:

@jondkinney Any chance of getting this PR merged?


Add inertia

Collisions should be able to impart rotational velocity

Reference - https://www.euclideanspace.com/physics/dynamics/collision/twod/index.htm
See subheading "Collision in 2 dimensions (with rotation no friction)"

See also - https://www.cs.ubc.ca/~rhodin/2020_2021_CPSC_427/lectures/D_CollisionTutorial.pdf
See subheading "How to solve a (single) collision"


twig extension classes are deprecated

Hello,
It looks as of twig 2.7, that Twig_Extension is deprecated according to phpstorm.
In researching the issue, it recommended replacing
 \Twig_Extension with \Twig\Abstract\Extension
Twig_SimpleFilter with \Twig\TwigFilter
Twig_SimpleFunction with Twig\TwigFunction
https://twig.symfony.com/doc/2.x/deprecated.html
let me know if I should make a pull request. Thanks
thanks.

It would be FANTASTIC if you could do a pull request for this @keyurshah

Fixed in https://github.com/nystudio107/generator-craftplugin/commit/a90cb8279cec99b243dca377e3facb62c669ef7b

Thanks! Sorry could not get to it. About to launch our commerce store this week hopefully!


About the Pyx calculation in "mesh" mode and "point cloud" mode

Hi, I had a few questions about the Pyx in your code and I hope you can give some insight for me!
First, What is the physical meaning of 'Pyx'?
Second, why is the Pyx calculated in different ways between "mesh" mode and "point cloud" mode? I noticed Pyx is used for calculating p2p in "point cloud" mode. Is Pyx in "mesh" mode can also used for calculating p2p?
Thanks in advance for your help!

Thanks for your interest. The Pyx is a soft point-wise correspondence matrix with the shape $N_y \times N_x$. During inference, if the input shapes are meshes, the method uses standard functional map pipeline to obtain the final p2p, while if the input shapes are point clouds, the method uses nearest neighbor search on the feature domain to obtain the final p2p. More details can be found in the corresponding paper.

Thanks for the reply!
So if my understanding is correct, Pyx in the functional map pipeline  Pyx = evecs_y.squeeze() @ Cxy.squeeze() @ evecs_trans_x.squeeze() is another way to calculate the final p2p (if we apply argmax func as in point cloud mode), yet the accuracy is not as high as the p2p calculated from functional map.
Is it reasonable that the results of p2p and Pyx are very different? Cause this is what I observed in my test data

Yes, it is reasonable. Because the purpose of this code Pyx = evecs_y.squeeze() @ Cxy.squeeze() @ evecs_trans_x.squeeze() is to create a soft point-wise correspondence for more smooth texture transfer but not for obtaining a more accurate p2p


Extract Expression Substitution code

Extracted substitution code from UI specific code so that
it can be used in other parts of the application. We would like
to use expressions with substitutions as Automate Method.

@gtanzillo @dclarizio
Please review

@gtanzillo @Fryguy
Please Review