Memory management patterns for C kata

Create a descriptions of patterns for memory management which would familiarize C authors with any approach other than "malloc everything".

I will move the discussion here, because I think it's difficult to discuss things in PR:
@ggorlen commented (https://github.com/codewars/docs/pull/231#pullrequestreview-566731480):

Interesting article with a lot of potential! While it offers some good food for thought and a few novel ideas I hadn't considered, my take is that it's a bit too opinionated and complicated for its own good.
In practice, in the majority of the C kata I've seen that require dynamic memory allocation, the solution function allocates its own memory with malloc and returns a pointer for the caller to free (the "naive" strategy discussed here). For LeetCode, where nearly all of the problems are translated into C, this strategy is applied across the board. The format consistency makes it easy to focus on the solution right away, and even with 2- or 3-d arrays, I've never found it unduly difficult/burdensome to malloc and return inner arrays and an array of sizes in the case of jagged arrays (as in this example).
That said, I agree with the guide that this "naive" approach isn't always better, both for kata and software engineering in general (important to consider if only to the extent that we don't want to recommend unusual/esoteric/questionable stuff), but it seems to be fine for most kata in practice. The preallocated buffer strategy is fine too and is a great fit for many kata types, but I'm not sure it's helpful to pick sides. Making authors aware of the characteristics of each without offering an opinion seems ideal.
As for the flattened nd arrays, reallocation and other approaches, these seem overly-complex. I can't imagine too many kata will need these. It's worth mentioning the flattened array approach because it exists, may be suitable for the occasional challenge and seems to align well with assembly language translations (I'm not sure, I've never done asm on CW), but is unlikely to mesh very well with typical translations coming from high-level languages that are overwhelmingly going to use multi-level nd arrays.

I will move the discussion here, because I think it's difficult to discuss things in PR:
@ggorlen commented (https://github.com/codewars/docs/pull/231#pullrequestreview-566731480):

Interesting article with a lot of potential! While it offers some good food for thought and a few novel ideas I hadn't considered, my take is that it's a bit too opinionated and complicated for its own good.
In practice, in the majority of the C kata I've seen that require dynamic memory allocation, the solution function allocates its own memory with malloc and returns a pointer for the caller to free (the "naive" strategy discussed here). For LeetCode, where nearly all of the problems are translated into C, this strategy is applied across the board. The format consistency makes it easy to focus on the solution right away, and even with 2- or 3-d arrays, I've never found it unduly difficult/burdensome to malloc and return inner arrays and an array of sizes in the case of jagged arrays (as in this example).
That said, I agree with the guide that this "naive" approach isn't always better, both for kata and software engineering in general (important to consider if only to the extent that we don't want to recommend unusual/esoteric/questionable stuff), but it seems to be fine for most kata in practice. The preallocated buffer strategy is fine too and is a great fit for many kata types, but I'm not sure it's helpful to pick sides. Making authors aware of the characteristics of each without offering an opinion seems ideal.
As for the flattened nd arrays, reallocation and other approaches, these seem overly-complex. I can't imagine too many kata will need these. It's worth mentioning the flattened array approach because it exists, may be suitable for the occasional challenge and seems to align well with assembly language translations (I'm not sure, I've never done asm on CW), but is unlikely to mesh very well with typical translations coming from high-level languages that are overwhelmingly going to use multi-level nd arrays.

TL;DR

I have a specific problem of clueless authors creating bad content which I am trying to solve. I would appreciate any suggestions how to approach it.
I agree that things are complex, but I believe the complexity is an inherent part and an essential feature of the problem and I do not know if/how it could be avoided. I would be glad to be proven wrong, or explained how to present things in an easy way.

One thing I should probably do is to put a guideline to "explain required allocation method" in this article: https://docs.codewars.com/languages/c/authoring/#compilation-warnings . I haven't put it there, because I thought a dedicated article would be better, but maybe it's not. Besides, it solves only a part of the problem.
Problem I am trying to solve
Then maybe we could proceed the other way round: I will tell you what problem I want to solve, and you will give me ideas how to solve it.
One of my concerns is that after attempting to solve several C kata (mostly low level ones, but not only), I've noticed that C translators come up with ideas which are, um... less than ideal, and after struggling with them several times  I would sometimes even bluntly call them retarded. There are kata which require you to:

dynamically allocate and return an int array of three elements to return hours, minutes, and seconds,
dynamically allocate an array of Point**, where each entry is a Point* being a pointer dynamically allocated, single instance of  Point structure,
return a Color* which points to a single instance of a dynamically allocated instance of a Color

These are the most prominent examples which put me in real awe, but there's also another class of problems, which require a more or less valid approach when you squint your eyes hard enough, but with insufficient specs:

requirement to return an array of dynamically allocated strings, where all entries could be (string) constants, like an array of { "NORTH", "NORTH", "WEST", "SOUTH", "NORTH", "EAST" }
totally missing specs on required allocation scheme for stringenums. You never know if returned string "Player1" or "Player2" is going to be freed or not. You generally flip a coin between a crash and a leak.
return type declared as int** which is not documented to be expected to be a dynamically allocated int (*arr)[3] and tests crash when solution returns an array of allocated arrays.

I could come up with a couple of more examples and rant on them in a very opinionated way, because they trigger me really hard ;)
As I've written somewhere, all I want to do is to stop this. I have a dream to read a description of a C kata one day and do not have to worry about a crash. I think it could be achieved by educating the authors and I wanted to create an article which would educate them.
Complexity of the article
I agree that the article ended up complex, and I do not like this either. I am asking for a review specifically to hunt for ideas to simplify it. I am afraid that the way how ideas are explained is too complex, and it can get readers discouraged rather than interested.
But I am not sure it can be avoided. I think that complexity of the memory management is an essential feature of the C language, and not just an incidental property of a task. Article is complex, because the topic is complex. Doing things correctly is hard, and understanding what is correct and what is not is hard. I am all for simplifying it, I just do not know how.
On the "naive approach" of malloc in solution, free in tests
Note: I might get some technical details wrong and if I am wrong, I would appreciate being educated here :)

In practice, in the majority of the C kata I've seen that require dynamic memory allocation, the solution function allocates its own memory with malloc and returns a pointer for the caller to free (the "naive" strategy discussed here). For LeetCode, where nearly all of the problems are translated into C, this strategy is applied across the board. The format consistency makes it easy to focus on the solution right away,

That said, I agree with the guide that this "naive" approach isn't always better, both for kata and software engineering in general (important to consider if only to the extent that we don't want to recommend unusual/esoteric/questionable stuff), but it seems to be fine for most kata in practice.

I seriously dislike this argument, for a couple of reasons. Saying that "It works" is just like saying that "I do not have to include this header, because it works." or "I can cast these pointers, it works" or "I do not have to use fuzzy equals, strict comparison works." . A SUT and its test suite are two logically separate things by definition, and performing de/allocations across logical boundaries is straight incorrect and a crash going to happen. There's no guarantee that the solution and the tests share the runtime, operate on the same heap, and share the memory metadata. It works due to specific character of what a kata is and how the solution is built. But still I consider it incorrect unless it's documented and made guaranteed to work .
Argument that "It works for others" is, uhm, even less of an argument :)
But even when it were made to work, I would still not be very fond of the idea. It would still be a cross-boundary de/allocation, which is invalid in C. It would make a good fit for Codewars kata, and a bad practice for C coding. It's just like relying on a system to have some specific locale set and getting an unexpected crash when regional settings change. Relying on a specific locale is wrong, assuming a size of a pointer is wrong, assuming that MAX_LONG > MAX_INT is wrong, closing a stream which you haven't opened is wrong, so wy writing a code which assumes that someone can free what they have not malloced is right? You do not create a kata where a solution opens a DB connection which tests would close. It seems to me as a gaping hole in a reasoning of "let's follow good coding practices when solving kata, except in C".
Thanks for listening, and thanks for bearing with me :)
CC @ggorlen @kazk  @error256

TL;DR

I have a specific problem of clueless authors creating bad content which I am trying to solve. I would appreciate any suggestions how to approach it.
I agree that things are complex, but I believe the complexity is an inherent part and an essential feature of the problem and I do not know if/how it could be avoided. I would be glad to be proven wrong, or explained how to present things in an easy way.

One thing I should probably do is to put a guideline to "explain required allocation method" in this article: https://docs.codewars.com/languages/c/authoring/#compilation-warnings . I haven't put it there, because I thought a dedicated article would be better, but maybe it's not. Besides, it solves only a part of the problem.
Problem I am trying to solve
Then maybe we could proceed the other way round: I will tell you what problem I want to solve, and you will give me ideas how to solve it.
One of my concerns is that after attempting to solve several C kata (mostly low level ones, but not only), I've noticed that C translators come up with ideas which are, um... less than ideal, and after struggling with them several times  I would sometimes even bluntly call them retarded. There are kata which require you to:

dynamically allocate and return an int array of three elements to return hours, minutes, and seconds,
dynamically allocate an array of Point**, where each entry is a Point* being a pointer dynamically allocated, single instance of  Point structure,
return a Color* which points to a single instance of a dynamically allocated instance of a Color

These are the most prominent examples which put me in real awe, but there's also another class of problems, which require a more or less valid approach when you squint your eyes hard enough, but with insufficient specs:

requirement to return an array of dynamically allocated strings, where all entries could be (string) constants, like an array of { "NORTH", "NORTH", "WEST", "SOUTH", "NORTH", "EAST" }
totally missing specs on required allocation scheme for stringenums. You never know if returned string "Player1" or "Player2" is going to be freed or not. You generally flip a coin between a crash and a leak.
return type declared as int** which is not documented to be expected to be a dynamically allocated int (*arr)[3] and tests crash when solution returns an array of allocated arrays.

I could come up with a couple of more examples and rant on them in a very opinionated way, because they trigger me really hard ;)
As I've written somewhere, all I want to do is to stop this. I have a dream to read a description of a C kata one day and do not have to worry about a crash. I think it could be achieved by educating the authors and I wanted to create an article which would educate them.
Complexity of the article
I agree that the article ended up complex, and I do not like this either. I am asking for a review specifically to hunt for ideas to simplify it. I am afraid that the way how ideas are explained is too complex, and it can get readers discouraged rather than interested.
But I am not sure it can be avoided. I think that complexity of the memory management is an essential feature of the C language, and not just an incidental property of a task. Article is complex, because the topic is complex. Doing things correctly is hard, and understanding what is correct and what is not is hard. I am all for simplifying it, I just do not know how.
On the "naive approach" of malloc in solution, free in tests
Note: I might get some technical details wrong and if I am wrong, I would appreciate being educated here :)

In practice, in the majority of the C kata I've seen that require dynamic memory allocation, the solution function allocates its own memory with malloc and returns a pointer for the caller to free (the "naive" strategy discussed here). For LeetCode, where nearly all of the problems are translated into C, this strategy is applied across the board. The format consistency makes it easy to focus on the solution right away,

That said, I agree with the guide that this "naive" approach isn't always better, both for kata and software engineering in general (important to consider if only to the extent that we don't want to recommend unusual/esoteric/questionable stuff), but it seems to be fine for most kata in practice.

I seriously dislike this argument, for a couple of reasons. Saying that "It works" is just like saying that "I do not have to include this header, because it works." or "I can cast these pointers, it works" or "I do not have to use fuzzy equals, strict comparison works." . A SUT and its test suite are two logically separate things by definition, and performing de/allocations across logical boundaries is straight incorrect and a crash going to happen. There's no guarantee that the solution and the tests share the runtime, operate on the same heap, and share the memory metadata. It works due to specific character of what a kata is and how the solution is built. But still I consider it incorrect unless it's documented and made guaranteed to work .
Argument that "It works for others" is, uhm, even less of an argument :)
But even when it were made to work, I would still not be very fond of the idea. It would still be a cross-boundary de/allocation, which is invalid in C. It would make a good fit for Codewars kata, and a bad practice for C coding. It's just like relying on a system to have some specific locale set and getting an unexpected crash when regional settings change. Relying on a specific locale is wrong, assuming a size of a pointer is wrong, assuming that MAX_LONG > MAX_INT is wrong, closing a stream which you haven't opened is wrong, so wy writing a code which assumes that someone can free what they have not malloced is right? You do not create a kata where a solution opens a DB connection which tests would close. It seems to me as a gaping hole in a reasoning of "let's follow good coding practices when solving kata, except in C".
Thanks for listening, and thanks for bearing with me :)
CC @ggorlen @kazk  @error256

I have a specific problem of clueless authors creating bad content which I am trying to solve. I would appreciate any suggestions how to approach it.
I agree that things are complex, but I believe the complexity is an inherent part and an essential feature of the problem and I do not know if/how it could be avoided. I would be glad to be proven wrong, or explained how to present things in an easy way.

I don't think there's an easy way to educate "clueless" authors on this topic. Delegating most of that to existing articles by linking to them is probably better than trying to write your own.
In general, inexperienced ones are not capable of considering trade-offs of different approaches because they only know one. Probably the best we can do is to present different approaches and briefly explain pros and cons for each. Then provide some guidance and links for them to learn further from.

When compared to other languages, C is complex by its nature, just like Haskell is difficult or JS is WTFy. Removing this essential aspects from a kata seems for me to artificially and forcibly skew the problem, and not to simplify it.

I recently learned this term:

Waterbed theory is the observation, ascribed to Larry Wall, that some systems, such as human and computer languages, contain a minimum amount of complexity, and that attempting to "push down" the complexity of such a system in one place will invariably cause complexity to "pop up" elsewhere.

The language C is pretty simple, but it's definitely not easy to use correctly. You're responsible for things that other languages let the computer do. It just requires you to be way more careful.
The C authors should be aware of the effects of their decisions and clearly document that. Making this clear is a good start.

because I think it's difficult to discuss things in PR

@hobovsky Do you want to use the GitHub Discussion (a new feature)? See https://github.com/codewars/docs/discussions/234

I have a specific problem of clueless authors creating bad content which I am trying to solve. I would appreciate any suggestions how to approach it.
I agree that things are complex, but I believe the complexity is an inherent part and an essential feature of the problem and I do not know if/how it could be avoided. I would be glad to be proven wrong, or explained how to present things in an easy way.

I don't think there's an easy way to educate "clueless" authors on this topic. Delegating most of that to existing articles by linking to them is probably better than trying to write your own.
In general, inexperienced ones are not capable of considering trade-offs of different approaches because they only know one. Probably the best we can do is to present different approaches and briefly explain pros and cons for each. Then provide some guidance and links for them to learn further from.

When compared to other languages, C is complex by its nature, just like Haskell is difficult or JS is WTFy. Removing this essential aspects from a kata seems for me to artificially and forcibly skew the problem, and not to simplify it.

I recently learned this term:

Waterbed theory is the observation, ascribed to Larry Wall, that some systems, such as human and computer languages, contain a minimum amount of complexity, and that attempting to "push down" the complexity of such a system in one place will invariably cause complexity to "pop up" elsewhere.

The language C is pretty simple, but it's definitely not easy to use correctly. You're responsible for things that other languages let the computer do. It just requires you to be way more careful.
The C authors should be aware of the effects of their decisions and clearly document that. Making this clear is a good start.

because I think it's difficult to discuss things in PR

@hobovsky Do you want to use the GitHub Discussion (a new feature)? See https://github.com/codewars/docs/discussions/234

Thanks for listening, and thanks for bearing with me :)

No problem, always happy to discuss and thanks again for putting so much energy into this! I hope I'm not coming across too critically, just want to toss in a somewhat fundamentally different take on it.

I agree that CW has some highly questionable code in its C repertoire, but on the other hand, I don't think that's unique to C--I've seen just as much garbage code in JS or Python on CW as I have with C.

C is Brainfuck of general purpose languages. When you have a problem and decide to solve it in C, you have two problems (unless you use regex too, then you have three). When you choose to solve a task in C, you've already committed to suffer. When compared to other languages, C is complex by its nature, just like Haskell is difficult or JS is WTFy. Removing this essential aspects from a kata seems for me to artificially and forcibly skew the problem, and not to simplify it.

I'm not sure it's all that bad. Sure, there's no STL which is significant, but after getting used to C, I don't typically find it fantastically harder than any other language (and occasionally, I find it's easier for certain types of problems, especially in the algorithm space). The point of saying this is just to suggest that I suspect a lot of our kata authors or translators should consider self-evaluating themselves out of the task if they feel C is overwhelming or uncomfortable.

Saying that "It works" is just like saying that "I do not have to include this header, because it works." or "I can cast these pointers, it works" or "I do not have to use fuzzy equals, strict comparison works."

I think you may be misunderstanding the proposal I'm making--it's essentially the same contract as fopen/fclose and other functions like asprintf and strdup. There is no correctness issue here--it's just a matter of whether the memory allocation is callee- or caller-managed. strcpy and sprintf would be examples of caller-allocated functions. Both are valid and useful in different circumstances.
The fact that LeetCode has applied the callee-allocated approach to hundreds of problems successfully, alongside ASAN seems like pretty strong evidence for it being an effective approach to coding challenges (most other online judge sites use stdout so I have to rely on LC).
Speaking of ASAN, part of the reason there's so much garbage C on CW is (I suspect) because it was written prior to Kaz enabling compiler warnings and better segfault messages a year-ish ago. When this was done, it pretty much borked a bunch of migrated CW content that took time to clean up and not be dumping walls of stderr to the runner.
I went to CW just now and clicked on the first C kata that came up, ran the test suite and got blasted with a wall of warnings. I don't have time to gather much more evidence to support my case but this seems indicative of the typical CW C kata.

So, what to do about all of this? My preferred approach would be to explain the characteristics of C memory management relevant to a typical kata (memory can be callee- or caller- managed, or both, and there are advantages and disadvantages to each approach), set forth the common pitfalls and present kata authors with a few simple examples they can work from, require that they resolve all compiler warnings, caution them about even approaching C authorship or translation if they're just starting out with C, then pretty much trust them to Do The Right Thing (tm).

Thanks for listening, and thanks for bearing with me :)

No problem, always happy to discuss and thanks again for putting so much energy into this! I hope I'm not coming across too critically, just want to toss in a somewhat fundamentally different take on it.

I agree that CW has some highly questionable code in its C repertoire, but on the other hand, I don't think that's unique to C--I've seen just as much garbage code in JS or Python on CW as I have with C.

C is Brainfuck of general purpose languages. When you have a problem and decide to solve it in C, you have two problems (unless you use regex too, then you have three). When you choose to solve a task in C, you've already committed to suffer. When compared to other languages, C is complex by its nature, just like Haskell is difficult or JS is WTFy. Removing this essential aspects from a kata seems for me to artificially and forcibly skew the problem, and not to simplify it.

I'm not sure it's all that bad. Sure, there's no STL which is significant, but after getting used to C, I don't typically find it fantastically harder than any other language (and occasionally, I find it's easier for certain types of problems, especially in the algorithm space). The point of saying this is just to suggest that I suspect a lot of our kata authors or translators should consider self-evaluating themselves out of the task if they feel C is overwhelming or uncomfortable.

Saying that "It works" is just like saying that "I do not have to include this header, because it works." or "I can cast these pointers, it works" or "I do not have to use fuzzy equals, strict comparison works."

I think you may be misunderstanding the proposal I'm making--it's essentially the same contract as fopen/fclose and other functions like asprintf and strdup. There is no correctness issue here--it's just a matter of whether the memory allocation is callee- or caller-managed. strcpy and sprintf would be examples of caller-allocated functions. Both are valid and useful in different circumstances.
The fact that LeetCode has applied the callee-allocated approach to hundreds of problems successfully, alongside ASAN seems like pretty strong evidence for it being an effective approach to coding challenges (most other online judge sites use stdout so I have to rely on LC).
Speaking of ASAN, part of the reason there's so much garbage C on CW is (I suspect) because it was written prior to Kaz enabling compiler warnings and better segfault messages a year-ish ago. When this was done, it pretty much borked a bunch of migrated CW content that took time to clean up and not be dumping walls of stderr to the runner.
I went to CW just now and clicked on the first C kata that came up, ran the test suite and got blasted with a wall of warnings. I don't have time to gather much more evidence to support my case but this seems indicative of the typical CW C kata.

So, what to do about all of this? My preferred approach would be to explain the characteristics of C memory management relevant to a typical kata (memory can be callee- or caller- managed, or both, and there are advantages and disadvantages to each approach), set forth the common pitfalls and present kata authors with a few simple examples they can work from, require that they resolve all compiler warnings, caution them about even approaching C authorship or translation if they're just starting out with C, then pretty much trust them to Do The Right Thing (tm).

Thanks guys for your inputs, I will try to reiterate on the article and see what I can come up with considering your remarks. Maybe I will just ditch it and put a guideline of clearly documenting the required format or allocated memory in the C authoring guide.
Just let me comment on one thing, but it's not something I am trying to push in any way, it's just somewhat related to a question I still have:

I think you may be misunderstanding the proposal I'm making--it's essentially the same contract as fopen/fclose and other functions like asprintf and strdup. There is no correctness issue here--it's just a matter of whether the memory allocation is callee- or caller-managed. strcpy and sprintf would be examples of caller-allocated functions. Both are valid and useful in different circumstances.

I agree that both approaches of callee- and caller-managed resources are valid and have their place, but strdup and asprintf are neither. Calle-managed memory would be when both allocation and deallocation are performed by means provided by a callee. Also strdup and others are somewhat different than "malloc in solution and free in tests". The former are deliberately designed this way and they transfer the ownership of the resource to a caller who might, or might not, be able to support the responsibility of managing it correctly. While for a kata, such "mixed approach" IMO can be  seen as a "design shortcut" at best, and an effect of "not knowing better" in majority of cases, which incidentally happens to work. However, under some circumstances, such mixed approach can also be considered valid, what brings me to the actual question:

A SUT [subject under test, i.e. submitted solution in context of CW] and its test suite are two logically separate things by definition, and performing de/allocations across logical boundaries is straight incorrect and a crash waiting to happen. There's no guarantee that the solution and the tests share the runtime, operate on the same heap, and share the memory metadata. It works due to specific character of what a kata is and how the solution is built. But still I consider [de/allocations crossing the boundary between solution and tests] incorrect unless it's documented and made guaranteed to work.

Am I getting this wrong? I am asking honestly, because maybe I am just remembering something incorrectly, or never knew right, or maybe I just mixed things up. Please correct me if I am wrong and explain where. Is the method of allocating in one place and deallocating in another guaranteed to work always? Is it guaranteed to work on linux? Is it guaranteed to work on Codewars? Maybe I just see an issue while it's not actually there, and all my rants are simply pointless? If so, I am really sorry for that and I would really appreciate being educated here!

Thanks guys for your inputs, I will try to reiterate on the article and see what I can come up with considering your remarks. Maybe I will just ditch it and put a guideline of clearly documenting the required format or allocated memory in the C authoring guide.
Just let me comment on one thing, but it's not something I am trying to push in any way, it's just somewhat related to a question I still have:

I think you may be misunderstanding the proposal I'm making--it's essentially the same contract as fopen/fclose and other functions like asprintf and strdup. There is no correctness issue here--it's just a matter of whether the memory allocation is callee- or caller-managed. strcpy and sprintf would be examples of caller-allocated functions. Both are valid and useful in different circumstances.

I agree that both approaches of callee- and caller-managed resources are valid and have their place, but strdup and asprintf are neither. Calle-managed memory would be when both allocation and deallocation are performed by means provided by a callee. Also strdup and others are somewhat different than "malloc in solution and free in tests". The former are deliberately designed this way and they transfer the ownership of the resource to a caller who might, or might not, be able to support the responsibility of managing it correctly. While for a kata, such "mixed approach" IMO can be  seen as a "design shortcut" at best, and an effect of "not knowing better" in majority of cases, which incidentally happens to work. However, under some circumstances, such mixed approach can also be considered valid, what brings me to the actual question:

A SUT [subject under test, i.e. submitted solution in context of CW] and its test suite are two logically separate things by definition, and performing de/allocations across logical boundaries is straight incorrect and a crash waiting to happen. There's no guarantee that the solution and the tests share the runtime, operate on the same heap, and share the memory metadata. It works due to specific character of what a kata is and how the solution is built. But still I consider [de/allocations crossing the boundary between solution and tests] incorrect unless it's documented and made guaranteed to work.

Am I getting this wrong? I am asking honestly, because maybe I am just remembering something incorrectly, or never knew right, or maybe I just mixed things up. Please correct me if I am wrong and explain where. Is the method of allocating in one place and deallocating in another guaranteed to work always? Is it guaranteed to work on linux? Is it guaranteed to work on Codewars? Maybe I just see an issue while it's not actually there, and all my rants are simply pointless? If so, I am really sorry for that and I would really appreciate being educated here!

Please see #235 and tell me if it helps anything.

Please see #235 and tell me if it helps anything.

Is the method of allocating in one place and deallocating in another guaranteed to work always? Is it guaranteed to work on linux? Is it guaranteed to work on Codewars? Maybe I just see an issue while it's not actually there, and all my rants are simply pointless? If so, I am really sorry for that and I would really appreciate being educated here!

Yes, you can allocate anywhere and deallocate anywhere else, there is no correctness issue. After compilation, functions are just instruction memory locations that are jumped to and the OS memory manager doesn't distinguish allocation and deallocation instruction locations, only sees the process as a whole making a system call. The issue is purely a matter of design with both options being useful and legitimate in various cases.
Although you're technically correct that asprintf and strdup are hybrid-managed, I'd argue that they still pretty much follow the callee-managed pattern with the nuance that the "destroy" routine is inlined because it's trivially free(s) (maybe I should have used the term "callee-allocated"). This makes sense because the allocated pointer is char *, not a complex opaque pointer/object context that may be refactored, so it's excessive abstraction to wrap it in a strdup_free-type routine that just calls free(s) always and forever. This "hybrid approach" happens to overlap with a lot of CW kata contracts and seems perfectly fine to me. The canonical callee-managed patterns as I understand them are:
Foo *f;
foo_init(f);
// do stuff with f
foo_destroy(f);

and
Foo *f = new_foo();
// do stuff with f
foo_destroy(f);

...with variants for different data types (these examples above are the "opaque pointer" pattern than what a typical kata would use with a char *, int * or int **). In many cases, of course, the function will also return the length of the array or an error status and allocate/populate memory, as in the fopen/fgets functions or calloc. The top pattern is basically fopen/fclose and the bottom pattern is strdup/asprintf/malloc itself if you grant that we can inline free for strings. All of this is "fair game" for designing a reasonable kata solution header.
Writing the foo_destroy routine is appropriate for "OOP" style challenges with opaque pointers, but not so much with char *, char **, int * and int ** that are the typical kata header structures. Having the solver write a separate arr_destroy function would probably be silly. For one, it's basically trivial to write and it just adds more noise that takes focus off the main task. For two, it may not even be necessary for the solver to write the function since memory leaks don't have a meaningful impact unless they're big enough to bring down the process, so there'd have to be an explicit test for that which seems like a waste of time in most cases (even writing such a test would be a PITA because crashing the process would kill the test suite, so you'd have to make a system call to get memory usage--yuck).
In short, in callee-managed kata, the kata author effectively writes the cleanup function as a simplification to keep the solver from tedious busywork that can't be easily tested anyway, then optionally inlines it into the test suite if it's as simple as free(arr) which is the common case int * that was malloc'd by the callee.

While for a kata, such "mixed approach" IMO can be seen as a "design shortcut" at best

I disagree--it seems plenty legitimate to me, both in terms of "real application" code and kata code (I've used the technique on probably dozens of challenges for Qualified). I'd encourage you to play through a few LeetCode C array challenges and see what you think, if you haven't yet.
One reason I think it works nicely for challenges is that the solver has more control and it creates signal that they follow best practices regarding malloc (important for Qualified). If they're overstepping array bounds and crashing, they only have to look at their own code instead of digging into the test suite to figure out how large the buffer they're given is (something that isn't possible in LC), so it gives a sense of agency to the solver that I find appealing. In many cases, how they use malloc vs calloc and realloc (or heck, asprintf/strdup even though they're non standard) is really fun/interesting and changes the solution dynamic considerably, whereas the preallocated-buffer solutions might all tend to look pretty much the same, depending on the nature of the kata.
Also, for many challenges, the size of the result array isn't necessarily known in advance (e.g. an array filtering operation like "give me all the even numbers in an array"), so the test boilerplate would essentially be giving away critical details and adding contrivance that likely wouldn't be known in a real scenario. UB is possible/likely when the solver hasn't correctly implemented the solution and writes past the preallocated buffer size, or the caller (test suite) assumes they've populated it fully but haven't. And, of course, allocating a massive chunk of memory to cover the possibility of excess only kicks the UB potential can down the road and is not a good look from a "best practices" standpoint, so I can't recommend it.
Again, there are so many knobs and nuances here so it's going to fall on the kata creator to use their C knowledge for good and make reasonable decisions for whatever kata they're making. But in general, I'd say:

Prefer callee-allocated memory when it's an OOP challenge with opaque pointers (not a common case), or the size of the result is variable (common case; filter an array, glue together an array of numbers into a string, etc). In rare cases, ask the solver to write the cleanup routine but the common case is to basically do it for them in the test suite.
Consider caller-allocated memory when the result size is fixed (ex: returning a 3-tuple of strings regardless of input size, rotate a matrix inplace, generate the next step of Conway's Game of Life, etc). No ambiguity that the caller handles cleanup.

Zooming back out (sorry for the longwinded explanation!), the main issues I have with CW C kata in descending severity are UB/compiler warnings/risky casts, sloppy/unreadable/golfed testing boilerplate, and to a lesser extent, weird solution headers and unusual design decisions. If the test suite leaks a bit of memory, requires a rather superfluous malloc or returns a char * when an enum would do, that's not great but not horrible either in my book. On the other hand, UB, compiler warnings and messy/minified boilerplate are horrible and I vote as the top priorities for docs to address. Memory management happens to play a role in all of this, especially UB and warnings.
I develop my C challenges offline and make sure they pass valgrind and emit no warnings. If CW kata always did this One Weird Trick, I think we'd be 90% of the way to awesome territory, with the remaining 10% being "don't minify/obfuscate your test suite" (duh!) and "don't pick weird function headers if you can help it" (rather nuanced and hard to explain).

Is the method of allocating in one place and deallocating in another guaranteed to work always? Is it guaranteed to work on linux? Is it guaranteed to work on Codewars? Maybe I just see an issue while it's not actually there, and all my rants are simply pointless? If so, I am really sorry for that and I would really appreciate being educated here!

Yes, you can allocate anywhere and deallocate anywhere else, there is no correctness issue. After compilation, functions are just instruction memory locations that are jumped to and the OS memory manager doesn't distinguish allocation and deallocation instruction locations, only sees the process as a whole making a system call. The issue is purely a matter of design with both options being useful and legitimate in various cases.
Although you're technically correct that asprintf and strdup are hybrid-managed, I'd argue that they still pretty much follow the callee-managed pattern with the nuance that the "destroy" routine is inlined because it's trivially free(s) (maybe I should have used the term "callee-allocated"). This makes sense because the allocated pointer is char *, not a complex opaque pointer/object context that may be refactored, so it's excessive abstraction to wrap it in a strdup_free-type routine that just calls free(s) always and forever. This "hybrid approach" happens to overlap with a lot of CW kata contracts and seems perfectly fine to me. The canonical callee-managed patterns as I understand them are:
Foo *f;
foo_init(f);
// do stuff with f
foo_destroy(f);

and
Foo *f = new_foo();
// do stuff with f
foo_destroy(f);

...with variants for different data types (these examples above are the "opaque pointer" pattern than what a typical kata would use with a char *, int * or int **). In many cases, of course, the function will also return the length of the array or an error status and allocate/populate memory, as in the fopen/fgets functions or calloc. The top pattern is basically fopen/fclose and the bottom pattern is strdup/asprintf/malloc itself if you grant that we can inline free for strings. All of this is "fair game" for designing a reasonable kata solution header.
Writing the foo_destroy routine is appropriate for "OOP" style challenges with opaque pointers, but not so much with char *, char **, int * and int ** that are the typical kata header structures. Having the solver write a separate arr_destroy function would probably be silly. For one, it's basically trivial to write and it just adds more noise that takes focus off the main task. For two, it may not even be necessary for the solver to write the function since memory leaks don't have a meaningful impact unless they're big enough to bring down the process, so there'd have to be an explicit test for that which seems like a waste of time in most cases (even writing such a test would be a PITA because crashing the process would kill the test suite, so you'd have to make a system call to get memory usage--yuck).
In short, in callee-managed kata, the kata author effectively writes the cleanup function as a simplification to keep the solver from tedious busywork that can't be easily tested anyway, then optionally inlines it into the test suite if it's as simple as free(arr) which is the common case int * that was malloc'd by the callee.

While for a kata, such "mixed approach" IMO can be seen as a "design shortcut" at best

I disagree--it seems plenty legitimate to me, both in terms of "real application" code and kata code (I've used the technique on probably dozens of challenges for Qualified). I'd encourage you to play through a few LeetCode C array challenges and see what you think, if you haven't yet.
One reason I think it works nicely for challenges is that the solver has more control and it creates signal that they follow best practices regarding malloc (important for Qualified). If they're overstepping array bounds and crashing, they only have to look at their own code instead of digging into the test suite to figure out how large the buffer they're given is (something that isn't possible in LC), so it gives a sense of agency to the solver that I find appealing. In many cases, how they use malloc vs calloc and realloc (or heck, asprintf/strdup even though they're non standard) is really fun/interesting and changes the solution dynamic considerably, whereas the preallocated-buffer solutions might all tend to look pretty much the same, depending on the nature of the kata.
Also, for many challenges, the size of the result array isn't necessarily known in advance (e.g. an array filtering operation like "give me all the even numbers in an array"), so the test boilerplate would essentially be giving away critical details and adding contrivance that likely wouldn't be known in a real scenario. UB is possible/likely when the solver hasn't correctly implemented the solution and writes past the preallocated buffer size, or the caller (test suite) assumes they've populated it fully but haven't. And, of course, allocating a massive chunk of memory to cover the possibility of excess only kicks the UB potential can down the road and is not a good look from a "best practices" standpoint, so I can't recommend it.
Again, there are so many knobs and nuances here so it's going to fall on the kata creator to use their C knowledge for good and make reasonable decisions for whatever kata they're making. But in general, I'd say:

Prefer callee-allocated memory when it's an OOP challenge with opaque pointers (not a common case), or the size of the result is variable (common case; filter an array, glue together an array of numbers into a string, etc). In rare cases, ask the solver to write the cleanup routine but the common case is to basically do it for them in the test suite.
Consider caller-allocated memory when the result size is fixed (ex: returning a 3-tuple of strings regardless of input size, rotate a matrix inplace, generate the next step of Conway's Game of Life, etc). No ambiguity that the caller handles cleanup.

Zooming back out (sorry for the longwinded explanation!), the main issues I have with CW C kata in descending severity are UB/compiler warnings/risky casts, sloppy/unreadable/golfed testing boilerplate, and to a lesser extent, weird solution headers and unusual design decisions. If the test suite leaks a bit of memory, requires a rather superfluous malloc or returns a char * when an enum would do, that's not great but not horrible either in my book. On the other hand, UB, compiler warnings and messy/minified boilerplate are horrible and I vote as the top priorities for docs to address. Memory management happens to play a role in all of this, especially UB and warnings.
I develop my C challenges offline and make sure they pass valgrind and emit no warnings. If CW kata always did this One Weird Trick, I think we'd be 90% of the way to awesome territory, with the remaining 10% being "don't minify/obfuscate your test suite" (duh!) and "don't pick weird function headers if you can help it" (rather nuanced and hard to explain).

Yes, you can allocate anywhere and deallocate anywhere else, there is no correctness issue. After compilation, functions are just instruction memory locations that are jumped to and the OS memory manager doesn't distinguish allocation and deallocation instruction locations, only sees the process as a whole making a system call.

Is the matter of multiple modules linked with different runtimes, and effectively operating on separate heaps, not an issue? Is it not a problem in general, or is it not a problem in Codewars setup?

Yes, you can allocate anywhere and deallocate anywhere else, there is no correctness issue. After compilation, functions are just instruction memory locations that are jumped to and the OS memory manager doesn't distinguish allocation and deallocation instruction locations, only sees the process as a whole making a system call.

Is the matter of multiple modules linked with different runtimes, and effectively operating on separate heaps, not an issue? Is it not a problem in general, or is it not a problem in Codewars setup?

Ah, I see what you're worried about. Interesting point but I don't think this applies here. I've never seen any evidence that the solution and test suite have different heaps. I don't know much about DLLs and most of linking and loading is magic to me (I have to preface everything by "I'm just another C challenge author, not a professional C developer"), so I can't explain exactly what's going on without looking into it further. Empirically, if this were unsafe, there'd have to be crashes following this pattern sooner or later but I've never seen them.
Curious if anyone can confirm/deny--this would be quite a revelation if I'm mistaken here!

Ah, I see what you're worried about. Interesting point but I don't think this applies here. I've never seen any evidence that the solution and test suite have different heaps. I don't know much about DLLs and most of linking and loading is magic to me (I have to preface everything by "I'm just another C challenge author, not a professional C developer"), so I can't explain exactly what's going on without looking into it further. Empirically, if this were unsafe, there'd have to be crashes following this pattern sooner or later but I've never seen them.
Curious if anyone can confirm/deny--this would be quite a revelation if I'm mistaken here!

Back in the days when I used to do professional development in C++ for Windows (it was not much, not directly in C but there were elements of it, and very long time ago, using Visual C++ 6, Win2000-era), problems with incompatible runtimes were somewhat easy to get into. You had multi-thredaded vs. single-threaded variants, debug and release variants, statically and dynamically linked variants, and in effect you ended up with a matrix of 8 possibilities of different compatibility levels. Compile one module with one set of settings, link with a module compiled with another set of settings, and BOOM, "your program has crashed". I was also much, much younger and I could understand something incorrectly or misremember things. But I remember debugging an issue of mismatching calls between strdup and free myself.
Granted, my experience is totally outdated, and related to different platform, and different setup. Things probably changed over time (there's no single-threaded runtime anymore in VS), things probably look differently on linux (is it common to have a runtime linked statically?) and probably does not apply to CW (it's unlikely that test suite and user solution would be compiled separately, with different compilation options). Or, doesn't it?
All what I was trying to discuss is whether the setup of CW runner is safe enough to support the way of constructing kata with asymmetric calls to malloc and free. I am almost certain that it's not generally safe, and I am just too unexperienced with current state of the art, of the technology, and of the CW setup, to tell whether it is safe in this particular setup. If it is universally safe, or even just safe for CW and we agree that it suffices to have kata set up in a way correct in context of CW and not "correct in general", then there's nothing more to discuss and I am just sorry I've wasted your time. However, maybe it is something worth considering, thinking about, or documenting.

Back in the days when I used to do professional development in C++ for Windows (it was not much, not directly in C but there were elements of it, and very long time ago, using Visual C++ 6, Win2000-era), problems with incompatible runtimes were somewhat easy to get into. You had multi-thredaded vs. single-threaded variants, debug and release variants, statically and dynamically linked variants, and in effect you ended up with a matrix of 8 possibilities of different compatibility levels. Compile one module with one set of settings, link with a module compiled with another set of settings, and BOOM, "your program has crashed". I was also much, much younger and I could understand something incorrectly or misremember things. But I remember debugging an issue of mismatching calls between strdup and free myself.
Granted, my experience is totally outdated, and related to different platform, and different setup. Things probably changed over time (there's no single-threaded runtime anymore in VS), things probably look differently on linux (is it common to have a runtime linked statically?) and probably does not apply to CW (it's unlikely that test suite and user solution would be compiled separately, with different compilation options). Or, doesn't it?
All what I was trying to discuss is whether the setup of CW runner is safe enough to support the way of constructing kata with asymmetric calls to malloc and free. I am almost certain that it's not generally safe, and I am just too unexperienced with current state of the art, of the technology, and of the CW setup, to tell whether it is safe in this particular setup. If it is universally safe, or even just safe for CW and we agree that it suffices to have kata set up in a way correct in context of CW and not "correct in general", then there's nothing more to discuss and I am just sorry I've wasted your time. However, maybe it is something worth considering, thinking about, or documenting.

Tests are linked together with solutions. Whether they are linked with the standard library statically or dynamically, the use the same library, so that shouldn't be relevant here.

Tests are linked together with solutions. Whether they are linked with the standard library statically or dynamically, the use the same library, so that shouldn't be relevant here.

I've reworked #231, please let me know if it's better and what would still have to be improved.
Thanks!

I've reworked #231, please let me know if it's better and what would still have to be improved.
Thanks!

I still don't like examples of using strings instead of enums...

If you really want to use strings for some reason

Isn't the tutorial for those who are not sure what to do? Those who have a good reason to really want to use strings, if one even exists, probably won't need the tutorial.
Thinking about other options... Preloaded can be used as a header with declarations and #defines and the solution can #include "setup.c".

I still don't like examples of using strings instead of enums...

If you really want to use strings for some reason

Isn't the tutorial for those who are not sure what to do? Those who have a good reason to really want to use strings, if one even exists, probably won't need the tutorial.
Thinking about other options... Preloaded can be used as a header with declarations and #defines and the solution can #include "setup.c".

The only reason why I left the suggestion of using strings is that I've seen authors and translators going defensive about my remarks of replacing them with enums, for various reasons. Most common reason was compatibility with other translations of the kata, usually high level languages.
I would be all for discouraging stringenums completely, I just did not want to force users and wanted to leave them some choice. I just thought that a suggestion of replacing strings with enums will be more friendly for translators than a hard guideline. But if you think it's not a good idea, then even better.

The only reason why I left the suggestion of using strings is that I've seen authors and translators going defensive about my remarks of replacing them with enums, for various reasons. Most common reason was compatibility with other translations of the kata, usually high level languages.
I would be all for discouraging stringenums completely, I just did not want to force users and wanted to leave them some choice. I just thought that a suggestion of replacing strings with enums will be more friendly for translators than a hard guideline. But if you think it's not a good idea, then even better.

Okay, since the questions about enums appeared quite often during review, I turned the recommendation into guideline. I removed  mentions of string constants and suggested turning them into enums. Let me know what you think.

Okay, since the questions about enums appeared quite often during review, I turned the recommendation into guideline. I removed  mentions of string constants and suggested turning them into enums. Let me know what you think.

#231 collected a couple of green check marks, so going to merge. If anyone notices any issues there, then let me know.
Thank you for reviews and for all your remarks, and sorry for wasting your time on this pointless discussion :)

#231 collected a couple of green check marks, so going to merge. If anyone notices any issues there, then let me know.
Thank you for reviews and for all your remarks, and sorry for wasting your time on this pointless discussion :)


Convert errors in socket callbacks

This pull request converts and logs errors in socket callbacks.
Closes #13

ok done. :shipit:


How to get the already selected phone code ?

delegate fpnDidSelectCountry only trigger when we select the country but what to do if you want to continue with already selected country ? Is there any way to get the value of already selected country code

@HanzalaRazaAnsari : Did you find any solution ?


Feature: mb reload --configfile

I run mountebank in a Docker (using docker-compose). I use mb save --savefile data.json to store the imposters/predicates to a file. I then modify this file locally.
It would be great if I could use the reverse method to reload mb from the configfile.

You can.  It's "mb restart --configfile data.json"
-Brandon
On Tue, Oct 3, 2017 at 6:14 AM, Ruud Kamphuis<EMAIL_ADDRESS>wrote:

I run mountebank in a Docker (using docker-compose). I use mb save
--savefile data.json to store the imposters/predicates to a file. I then
modify this file locally.
It would be great if I could use the reverse method to reload mb from the
configfile.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bbyars/mountebank/issues/296, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAESvyzLSDR7zhbyH3RDsuqxkeCy2Fedks5sohcogaJpZM4Pr8xe
.

The issue is, that in a Docker container, the docker container's process is mb. When you call mb restart it will kill the process (to try to restart it). But starting won't work because when the process stops, the docker container is stopped.

Actually, it would be better if Mountebank would always just scans for file changes and reloads automatically.

Are you able to put this hot reload feature back on roadmap?
I experienced the same behavior.
As I do changes in the esj files, I have to reload mountebank.

I found a good workaround via REST API in
https://github.com/telekom/mb-netmgmt/blob/53c73b7bc46682923a7f59ede8bc7dd807117717/mb_netmgmt/__init__.py#L58
You send always a PUT in an infinite loop with your imposter configuration to emulate a "hot reload".

Thanks for posting the workaround!
On Thu, Feb 23, 2023 at 5:29 AM GRIBOK @.***> wrote:

I found a good workaround via REST API in
https://github.com/telekom/mb-netmgmt/blob/53c73b7bc46682923a7f59ede8bc7dd807117717/mb_netmgmt/__init__.py#L58
You send always a PUT in an infinite loop with your imposter configuration
to emulate a "hot reload".
—
Reply to this email directly, view it on GitHub
https://github.com/bbyars/mountebank/issues/296#issuecomment-1441599756,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAARFP7FNIPVEYEAWM2EHQLWY5CZ7ANCNFSM4D5PZRPA
.
You are receiving this because you commented.Message ID:
@.***>


Error: 'Size' is imported from both 'dart:ffi' and 'dart:ui'

I am working with a Flutter app that uses this library. I am getting this error because Size is used in both ffi and ui library. The solution I found is to hide Size from one library in windows.dart file in Windows and Linux platforms like this.
import 'dart:ffi' hide Size;
But this solution is not good, because every time we pull, same error appears. I am not used to work with open source code. Author or anyone update this on Github so that next time, I pull, I will not face this error. Thanks.

Fixed in bitsdojo_window: ^0.1.2 - https://github.com/bitsdojo/bitsdojo_window/commit/f320b623db107b03a5976fd88e52ec4fe81fa0c9
Closing this issue. Please re-open if needed.

🎉 🎉 🎉


Download Binary Flagged by Windows Defender: Trojan:Win32/Wacatac.B!ml

[Trojan:Win32/Wacatac.B!ml](webfile: C:\Users\LocalUser\Downloads\vcgopkg-amd64.exe|https://objects.githubusercontent.com/github-production-release-asset-2e65be/351894694/4c6fc11f-643d-4f47-bc99-de3f542f1173?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230330%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230330T043334Z&X-Amz-Expires=300&X-Amz-Signature=cda239c782ce3fcf0c4c4a65e34d2fc2ba4e044b099163ea0db4212f47ead993&X-Amz-SignedHeaders=host&actor_id=7209562&key_id=0&repo_id=351894694&response-content-disposition=attachment%3B%20filename%3Dvcgopkg-amd64.exe&response-content-type=application%2Foctet-stream|pid:1904,ProcessStart:133246244158402859)
https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3AWin32%2FWacatac.B!ml&threatid=2147735505

From Microsoft:

vcgopkg-amd64.exeSubmission ID: 6f90cad6-d41e-40b4-bb74-7f6a91872526Status: In progressSubmitted by: bbaukema@veracode Submitted: Mar 30, 2023 08:59:26User Opinion: Incorrect detectionAnalyst comments:
We cannot reproduce any detection on the file. If the detection is still observed, follow the steps below to capture support log files from the system reporting detection.
From an elevated command prompt, change to directory "%programfiles%\windows defender" and execute mpcmdrun.exe with option GetFiles:
cd "%programfiles%\windows defender"
mpcmdrun.exe -GetFiles
All created log files will be compressed into MPSupportFiles.cab. Please send us the detected file and MPSupportFiles.cab using https://aka.ms/wdsi. We will continue the investigation once we receive the support log files.
Thank you for contacting Microsoft.

Please consider ensuring your signatures are up-to-date and if they are and you're still getting this reported please follow the guidance above and submit to https://www.microsoft.com/en-us/wdsi/filesubmission


Add Min Documentation

2 Drink Minimum

This PR addresses adding the Min Monoid on [this issue] (https://github.com/evilsoft/crocks/issues/42) by adding the README for Min

Coverage remained the same at 100.0% when pulling 0adf8660808da28c27da7bad5f32aa7f337948d0 on min-docs into 78f6014557e53d7945d9c76ac81b1beb71bb9a41 on master.


fix: filter by value only with line chart with coordinate data

Please check if the PR fulfills these requirements

[x] It's submitted to right branch according to our branching model
[x] It's right issue type on title
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes/features)
[x] Docs have been added/updated (for bug fixes/features)
[x] It does not introduce a breaking change or has description for the breaking change

Description
#193
change condition

Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

리뷰 완료했습니다. 수고하셨습니다.


Bulk Command Sender Fixes

I've fixed the following:

Less ORM
Admins can now send bulk commands to ALL servers on their nodes.

It's bothering me that travis is having issues building your PRs. I'm going to play around with it a bit and see what's going on before I merge this in.

@LordRalex I'm not sure what the problem is with Travis, but I agree that it is indeed weird.
I developed this on my live Puffer instance.

I'm certain the problems are not with your stuff, but it's easier when I can use an existing PR to re-test things.


[Wiki] Installation script

Running the dependency script will give me error message "There are problems and -y was used without --force-yes".
Adding --force-yes flag before -y can solve this error.
My OS: Ubuntu 14.04.3 desktop amd64bit

There might be problems in your installation. Quoting from http://manpages.ubuntu.com/manpages/raring/man8/apt-get.8.html :

--force-yes is a dangerous option that will cause apt to continue without prompting if it is doing something potentially harmful. It should not be used except in very special situations.

So, I think it is a bad idea to add that flag.


configure PHPStan

Add PHPStan configuration and fix code to meet PHPStan requirements

The code needs to be refactored, before a PHPStan action may be added to the workflow. This is not a simple fix. See issue #8


Order by columns not work properly

When I try to do sort per column it not return the correct sort (asc/desc)

I have a similar issue actually. I am getting a larger data set imported to narrow down the issue. I know on my implementation, I have several joins in the MySQL statement. So not sure if that plays a factor or not. But I noticed at least one or two rows which would not remain in order. Like if I sort dates, there would be a date that would remain out of order.

Can I see your sql query string?
And which db you are using?

MySQL
SELECT reg.id, reg.payment_method as type, reg.source, reg.firstname, reg.lastname, reg.email,
evt.id as evtid, evt.title, loc.id as locid, loc.city, loc.state, evt.start, reg.status, trans
.promocode_discount, trans.promocode,
trans
.groupdiscount,
trans.earlybird, (trans.amount/trans.tickets_purchased) as amount FROM event_registration as reg
LEFT JOIN events as evt ON reg.event = evt.id LEFT JOIN event_locations as loc ON evt.location = loc.id
LEFT JOIN transactions as trans ON reg.parent = trans.uid
LEFT JOIN event_categories as cat ON evt.category = cat.id

That seem to be something related joins.
Can you try changing join type ? And try again later ?

I updated the JOINS and it didn't help. I did, however, discover the issue. Several of the selects are used primarily for logic display and are later hidden using your framework code.
I realized if I keep the 'hidden' selects at the end of the query i.e. SELECT id, type, firstname, lastname, email, hidden.field, hidden.field the sorting started working correctly. Guessing the columns are assigned in order on the query, so any hidden columns need to be set last.
So not sure best way to document for anyone else encountering a similar issue, but that appears to be what resolved it for me. I haven't merged my primary database yet, but will report back if I see my resolution didn't work on the full dataset.

hmm.. I see. As you say there is a bug in hide() method or near it.
Can you test https://github.com/n1crack/datatables/tree/2.0-dev  branch? It might have already fixed.

I don't think the bug is in the hide method unless that connects to the ordering. Unfortunately not too much time to review all the commits at the moment. I did see this: $this->columns->getByIndex($order['column'])->isOrderable(); in the commit. It would appear that possibly you're retrieving the index by the order of the 'columns' MySQL retrieves. Since the column ordering is done left to right in the SELECT statement, my guess is the columns are established in the same way -> left to right-> index 0, 1, 2, 3...
The columns themselves display as normal, as when I 'hide' them datatables doesn't try to pull them and I can use the data as part of edit or add functions as designed. The issue seems to be, it doesn't seem to reverse index them, at least on my version. Meaning if you select them in an arbitrary order with hidden columns between the 'displayed' ones, when ordering it uses the 'hidden column' as the basis for it's ordering.
So as stated, the 'visible' columns I added to the far left in the order they display and then any hidden columns I amended to the end of the SELECT portion of the statement.

Wow, thanks man! That will be helpful with some of my more advanced queries where I need many columns but utilize those columns for logic processing before going to DataTables. You're awesome.


Vintage Microphone Lag

Using the Vintage Microphone destroys my FPS, making the game lag for at least 3 seconds. I am not sure why this happens, my PC is good enough (intel i7 4770, gtx 1070, 16GB RAM)

Are you sure that it's lag and it's not just you getting knocked around by the projectiles? I broke something and now the projectiles actually collide with entities, which can cause choppy camera movement because you're being instantly moved by a few units.

Hi, I am certain it was lag. I'll try to record it for you the next time I play risk of rain. Cheers.

I have just uploaded a patch to Thunderstore that has a few code changes to Vintage Microphone. Update the mod and let me know if this issue is still present or if we can close it.

Hey, I checked it and it got fixed. Cheers!


Fixes memory leak. Works around compiler optimization bug...

.... (as of Xcode 6.2 beta 3 (6C101)), which resulted in no data being returned for optimized builds (e.g. Release builds by default); this is achieved by doing the keychain read from Objective-C, which although not pretty is less nuclear than disabling compiler optimization for the whole Swift project.

Thank you!


[CLI-336] Deprecation not always reported

fixes for CLI-336
updated javadoc for OptionGroup.getSelected(), OptionGroup.isSelected() and OptionGroup.select() methods to indicate that deprecated options do not trigger logging of deprecated option usage.
CommandLine methods hasOption(OptionGroup), getOptionValue(OptionGroup), getOptionValues(OptionGroup),  and getParsedOptionValue(OptionGroup) methods.

I don't understand how coverage checks can not be met when the added methods are covered based on jacoco report.

Codecov Report
Attention: Patch coverage is 12.50000% with 14 lines in your changes missing coverage. Please review.

Project coverage is 94.87%. Comparing base (9f6b23b) to head (205d7b8).
Report is 223 commits behind head on master.

Files
Patch %
Lines

.../main/java/org/apache/commons/cli/CommandLine.java
12.50%
13 Missing and 1 partial :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #284      +/-   ##
============================================
+ Coverage     91.90%   94.87%   +2.97%
- Complexity      575      661      +86
============================================
  Files            22       23       +1
  Lines          1247     1386     +139
  Branches        210      227      +17
============================================
+ Hits           1146     1315     +169
+ Misses           63       38      -25
+ Partials         38       33       -5

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

Codecov is currently broken. Uploads now require an authentication token for the master branch, but apparently not for PR branches. The master build codecov upload failed, see last CI build. So although the codecov uploaded from this PR, there is no record for the base commit and codecov errors with missing coverage.
There is a ticket to resolve this by adding a token to all commons repos: INFRA-25729. However generating an org level token requires an org level github account and apache does not have one. So this is an unresolved issue.
It may require a move away from codecov to some other tool, or negotiation with codecov to provide an alternative authentication mechanism for open source repos.

I don't understand how coverage checks can not be met when the added methods are covered based on jacoco report.

@Claudenw
You are NOT testing ALL of the new APIs added in this PR.
Run:
mvn clean install site -P jacoco -Dcommons.jacoco.haltOnFailure=false

Then open target/site/jacoco and navigate to CommandLine and the untested code will be marked in red.

@Claudenw ping

I am traveling and moving over thenext two weeks.  I hope to get to this later this week, time permitting.

@Claudenw
Good luck 👍  with the move 💪

Hi @Claudenw
Thank you for your updates 😄
Is this PR ready? If so, you have to change the status from "draft" to "ready for review", then it can be merged.


EV-8 - Barebones inner docs

Initial barebone skeleton and APIs

Cancelling pull request since "secret" keys we shared?


Add @naseemkullah to approvers / CODEOWNERS

Given his regular contribution to OpenTelemetry JS, propose that @naseemkullah is granted Approver status.

Thank you @dyladan and gang! 🤩

Welcome aboard!

Welcome aboard!

Thanks @mayurkale22 !


  For example in 1.9 the following prints OK
docker stop foo && docker stop foo && echo OK

In 1.10 you get
404 Client Error: Not Found ("No such container: a915")

This is change in the API, not just the CLI.  I tested this against the API.

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

I got this;
$ docker run -d --name foo nginx
9f1071d2eaa94e6699bd4d4634bd751a09b1dc4afe23c72c7bef32d496af4428
$ docker stop foo && docker stop foo && echo OK
foo
foo
OK

What distro are you running on? There is a known issue with AppArmor that causes docker to not run correctly on Ubuntu 14.04 and below fwiw

@thaJeztah Odd.... let me try this again or give a better test case.  I'm running RancherOS :smile:

Okay, closing.  No clue what I did to create this issue to begin with.  I swear I tested it a bunch of ways (even through the API).

@ibuildthecloud ahhhh RancherOS :trollface:
Jut kidding, no problem, feel free to reopen if you are able to reproduce :heart:


Improve views

I had a quick look and I don't see the differences in what this is changing, can you clarify please?

I get it now sorry, it's semantic changes which are welcome, if you can take a look at the inline comment above I will merge :)


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix html repr in untrusted notebooks (plain text fallback)

[x] Closes #4041
[x] Tests added
[x] Passes isort -rc . && black . && mypy . && flake8
[x] Fully documented, including whats-new.rst for all changes and api.rst for new API

This is not very elegant (actually plain text repr is already included in the notebook as text/plain mime type but it is ignored when text/html mime type is present), but it seems to work. I haven't found a better workaround.
I don't really know if this can be properly tested (I only added a basic test).
Steps to test this fix:

To "untrust" a notebook: open an existing notebook with a simple editor, manually edit one output cell with a xarray object repr, and save the ipynb file.
Open this notebook with the Notebook app, you should see the plain text repr.

I tested this out exporting a notebook to Github:
https://gist.github.com/shoyer/6ee36acd164116fee4681f6237ca5249
Here's what I see:

Somehow we get both text and malformed HTML? :(

Mmm it looks like Github's notebook renderer removes the hidden attribute of the xr-wrap div in addition to removing CSS. That's unfortunate.
I tested this workaround in jupyterlab, classic notebook and nbviewer. It works as expected. I haven't tested other front-ends (Colab, vscode, etc.).

I sent a support request to GitHub asking for supporting the hidden attribute. We'll see if we get a response!

Thanks @benbovy

just confirmed that the fallback works perfectly. Thanks @benbovy !


EEPROM emissivity change

Hi,
I'm playing with the emissivity which can be configured in the EEPROM of the MLX90615, and there is something strange when I try to modify it: it doesn't seem to change, unless I zero-out the configuration prior to setting the new value.
Here are the details: let's say the MLX90615 is configured with the defaults (1.0 emissivity): a call to readEEPROM shows in the console
eepromData: 0x4000

Fine. Now let's try to set the emissivity to 0.98, with the following code:
float emissivity = 0.98;
uint16_t emissivity_internal;

emissivity_internal = uint16_t(16384*emissivity);

mlx90615.writeEEPROM(emissivity_internal);
mlx90615.readEEPROM();

I'm expecting in this case an eepromData: 0x3EB8, but no, I keep on reading an eepromData: 0x4000, even if I call this code several times.
Things work as expected only if I zero-out the emissivity prior to trying to set it to 0.98 for example. This workaround apparently works fine:
float emissivity = 0.98;
uint16_t emissivity_internal;

emissivity_internal = uint16_t(16384*emissivity);

mlx90615.writeEEPROM(0);
delay(500);

mlx90615.writeEEPROM(emissivity_internal);
mlx90615.readEEPROM();

Note the call to delay which is necessary between two calls to writeEEPROM.
Do you have the same problem with other chips? I'm using your grove sensor.

Section <IP_ADDRESS>.2 of the datasheet:
Note: Before a write operation takes place, the EEPROM cell needs to be erased.
An erase operation is simply a write of 0000h at the same EEPROM address.
Care needs to be taken not to alter factory calibration (EEPROM addresses 4…Dh).

Well, I think it's clear enough! :)
I just have to understand this timing problem that forces me to use a delay(500)after erasing the EEPROM.

I'm sorry that I didn't have time to deal with your problem. This issue is closed first. If you still need to discuss, you can reopen it, and we will try our best to help you


[TEST] Medley

Current coverage is 62.46%

Merging #1534 into develop will increase coverage by +0.17% as of 79c3ec3

@@            develop   #1534   diff @@
=======================================
  Files           892     893     +1
  Stmts         63175   63234    +59
  Branches          0       0
  Methods           0       0
=======================================
+ Hit           39358   39496   +138
  Partial           0       0
+ Missed        23817   23738    -79

Review entire Coverage Diff as of 79c3ec3

Powered by Codecov. Updated on successful CI builds.


polished spring cloud square commit

This is a polished version of the existing square PR https://github.com/spring-projects-experimental/spring-native/pull/891 - however, this should not be merged until Spring Cloud Square 0.4.0 M2 is released - currently it just uses the SNAPSHOT for 0.4.0.

Potentially related to #1076.


Replace $ vite build && vite build --ssr with $ vite build + enable plugins to add build step

Clear and concise description of the problem
We want to build deploy plugins, e.g. vite-plugin-cloudflare-workers, vite-plugin-vercel, and vite-plugin-deno-deploy.
Currently, the user would need to:
// package.json
{
  "scripts": {
     "build": "vite build && vite build --ssr && vite-plugin-cloudflare-workers build"
  }
}

Suggested solution
// package.json
{
  "scripts": {
     // Automatically runs all three build steps:
     // 1. client bundling
     // 2. SSR bundling
     // 3. custom build step (defined by the plugin)
     "build": "vite build",
  }
}

// vite.config.js
import cloudflareWorkers from 'vite-plugin-cloudflare-workers'
export default {
  plugins: [ cloudflareWorkers() ],
  server: './path/to/server.js'
}

Additional context
There is an increasingly number of deploy environments.

Deno Edge (which supports Vite apps)
Supabase Functions
AWS Lamda
AWS EC2
Cloudflare Workers
Netlify Functions
Vercel
...

This ticket enables deploy plugins which in turn enables deeper collaboration between SSR frameworks.
Eventually it is the deploy providers who will maintain these plugins. (Like how Cloudflare Workers took over miniflare.)
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

I'm going to put some time on this one. See if I can tackle it down!
Thanks.

@aleclarson Thoughts on this? Could be relevant for https://github.com/alloc/viteflare.

@brillout would you extend the API you are proposing? In your config example, server is used but that is the Vite Dev Server config already. And how do the plugins communicate that they have a build step that should be executed?

I'm glad this is getting attention. There is a big need for shared deploy adapters & plugins that the whole Vite ecosystem can use. Instead of having vps, SvelteKit and Astro re-invent the wheel. (@cyco130 is experimenting on something quite exciting in that space, and @magne4000 is working on vite-plugin-vercel which supports Vercel's ISR platform.)
I think the writeBundle() hack is, actually, quite neat. It's flexible, as you can see.
Being able to append tasks to $ vite build is AFAICT enough. So I'm proposing we introduce a new Vite hook onBuildEnd() that enables the writeBundle() hack in an official way: onBuildEnd() is guaranteed to run last and supports side effects. That way plugins and frameworks can safely append tasks to $ vite build.
The neat thing here is that we can re-use Vite's enforce mechanism to resolve plugin conflicts. For example, vps would use enforce: pre while the deploy plugins use enfore: post, so that the sequence is: 1. client bundling, 2. server bundling, 3. pre-rendering, 4. deploy specific build (e.g. ncc for Next.js or Cloudflare Workers' wrangler for bundling the server-side into a single worker code).
I'd suggest to experiment with the writeBundle() hack for a while and see how it goes. If it works well let's go for an official support with something like onBuildEnd().
As for defining new commands, I don't see much complications here. One thing though: other than $ vite deploy, I don't see a use case for defining new commands. So I'm thinking we could simply add a new $ vite deploy command that does nothing by default; a plugin has to define what it does.

vps

Just FYI, this acronym is a bit confusing / overloaded because we also use it for vite-plugin-svelte

There is a big need for shared deploy adapters & plugins that the whole Vite ecosystem can use. Instead of having vps, SvelteKit and Astro re-invent the wheel.

I was previously supportive of this, but unfortunately it's gotten a bit more complicated on our side. SvelteKit has introduced server-side route splitting. This means that SvelteKit's adapters now have to know how to map SvelteKit routes to the routing functionality of each hosting platform. As a result, it'd be hard to share given the need for SvelteKit-specific logic. Perhaps there could be general adapters and each framework could provide their own route-splitting functionality, but it's gotten more complicated at least

This means that SvelteKit's adapters now have to know how to map SvelteKit routes to the routing functionality of each hosting platform.

I've talked a bit about Saus recently (for those who missed it: link), which could provide routing primitives and route-based code splitting if Vite decides not to go that route (no pun intended). The vision is that full-stack frameworks share a lot more in common than they're currently taking advantage of, so there should be a layer like Saus that helps with that. Such a layer would be a lot better of a candidate for a deployment adapter API that every Vite-based framework could use (indirectly through plugins). Finally, there was a Twitter thread all about this direction just recently (link).

Here's the work I've done that @brillout refers to: https://github.com/cyco130/vavite (in particular the @vavite/multibuild and @vavite/multibuild-cli packages, in the last paragraph of the readme).

I agree that given the current parallel explorations happening it may be too soon to formalize things in Vite core. @brillout your idea of a new onBuildEnd hook is interesting, but it feels a bit hacky to me. Shouldn't the non-ssr build and the ssr one be more on the same level? How do we offer the user the possibility to parallelize the build steps.
And @cyco130's multibuild buildSteps may have the same issue, no?
I see the appeal to have this in core though, as everyone in the ecosystem will end up reinventing the wheel if not. But looks like we are getting into the business of a task runner, and we should then have a task DAG. Maybe instead of a onBuildEnd we need a registerBuildTask hook if we take this responsibility in Core.

And @cyco130's multibuild buildSteps may have the same issue, no?

My idea was to extend it later with requires or something like that to support parallelization (effectively turning it into a DAG task runner like you describe).

Do we really need a DAG? I do agree that a real task runner needs to be a DAG, but we only have a handful of tasks.
Concretely, $ vite build will always be composed of max 3 build steps:

Rollup bundling
Pre-rendering
Deploy worker bundling

Also note that pre-rendering needs to await Rollup bundling; we cannot parallelize these two.
For only three steps, I don't think we need a DAG. But maybe there are more steps I'm not foreseeing.
I propose we start without a DAG at first and see how it goes.

Shouldn't the non-ssr build and the ssr one be more on the same level?

Good point. I'm 👍 for replacing $ vite build && vite build --ssr with $ vite build + a new config. Although, I think it's lower priority and things are working out so far. I suggest to consider deploy adapters & plugins to be the highest priority thing here. We can always parallelize and "DAGify" things later.
The world is ripe for deploy adapters. If Vite delivers on this, that's big. Guillermo Rauch (Vercel CEO) is supportive, and Cloudflare Workers, I'm confident, will shortly follow, and with it all other deploy providers.

a new onBuildEnd hook is interesting, but it feels a bit hacky to me.

That's how I felt at first as well, but I ended up liking it. Because it fits well with the current Rollup plugin architecture. it's simple and it works. We can use the enforce mechanism instead of a DAG. Yes it's cheap but, for only 3 build steps, it works.
Anyways, in the meantime, let's see how things go with the writeBundle() hack.

Is the idea that this command would execute a deploy hook from plugins?

Yes.

Wouldn't we have the same issue of needing a DAG to control what can be done in parallel?

Only one plugin is allowed to define the deploy() hook. For a given app, there would be only one deploy plugin. E.g. either vite-plugin-vecel or vite-plugin-cloudflare but not both. There may be some edge cases that warrant the use of two deploy plugins, but I think it's ok for now to not support these edge cases.
Also CC'ing @Aslemammad who's working on vite-plugin-cloudflare.

As for the off-topic discussions, see:

https://github.com/vitejs/vite/discussions/7700
https://github.com/vitejs/vite/discussions/7701

SvelteKit has been updated so that all building occurs within a Vite plugin. Calling vite build && vite build --ssr seems too clunky so we're instead programatically invoking vite a second time from the writeBundle hook

SvelteKit has been updated so that all building occurs within a Vite plugin. Calling vite build && vite build --ssr seems too clunky so we're instead programatically invoking vite a second time from the writeBundle hook

Same for vite-plugin-ssr 0.4.
I believe Rakkas also does this (although it uses another hook IIRC).
Let's see how this pans out.

I just released vite-plugin-ssr 0.4 that includes the writeBundle chaining trick.
Implementation: https://github.com/brillout/vite-plugin-ssr/blob/514843f92af77324d5038169ea2f45bfe7db7816/vite-plugin-ssr/node/plugin/plugins/autoFullBuild.ts.
Let's see how it works out.

SvelteKit has five build steps that must be run sequentially as each depends on the output of the step before it.
I think a nice way to support this would be if Vite supported an array of configs just as Rollup does. Our builds could potentially look something like:
export default [
  {
    plugins: [svelteKitClient()]
  }
  {
    plugins: [svelteKitServer(), svelteKitPrerender()]
  }
  {
    plugins: [serviceWorker()]
  }
  {
    plugins: [adapterVercel()]
  }
];

Right now, we're kicking off the server, prerender, and service worker from writeBundle and adapter from closeBundle. The client, server, and service worker each require bundling. Some of the adapters are running a bundling step as well with esbuild (depends on the target platform and user options). The prerender step is just writing files out, so may not need its own bundling step.
We've reached the limits of this approach. We're trying to let people optionally switch out our service worker implementation for vite-plugin-pwa, but there's no way to make this work. The service worker generation has to happen after prerendering is run and before our deploy adapters run. However, writeBundle and closeBundle are both parallel hooks, so there's no way to enforce this. If vite-plugin-pwa uses writeBundle there's no guarantee our prerendering has finished. If vite-plugin-pwa uses closeBundle there's no gaurantee it will finish before our adapter begins.
Allowing these to be separate builds or have more build steps would also allow us to refactor more of this to occur in shareable Vite plugins. E.g. as @brillout mentioned above, if adapters were Vite plugins then they could be shared across the ecosystem.
An alternative solution may be to have Rollup change writeBundle or closeBundle from parallel to sequential for Rollup 3 or to have Vite add a new sequential hook somewhere towards or at the end of the build. Then we could keep doing what we're doing while running into fewer ordering problems between the plugins.

@benmccann Is there actually a need for multiple builds in vite.config.ts files, or is support through programmatic API enough? That would avoid the breakage of other tools that load Vite configs.

@aleclarson we need to run multiple builds, but they don't have to be defined via vite.config.ts. Other solutions like the addition of a sequential hook would work as well or possibly even making enforce: 'pre' and enforce:'post' group and await plugins when executing parallel hooks (https://github.com/vitejs/vite/pull/9326#issuecomment-1193282124). Open to other ideas as well if you had something else in mind when referring to programmatic API. I think I'm probably leaning towards a new hook as being my favorite solution

writeBundle closeBundle parallels executing

I agree this is something limiting the ecosystem to grow and innovate. And we should figure out a better way to improve it. While changing it to complete sequential will hurt the performance and probably be a significant breaking change to the ecosystem. I'm thinking maybe we could have it per-plugin level control of whether those plugins should be executed parallel or sequential. We might need to figure out a good design of how we could express it by extending the current API.

Multiple builds in vite build

In general, I am against doing this. Even if it can be possible, I would personally think it's a bit anti-pattern. Vite as a front-end tool is mainly for building the client app, given its pretty low-level, meta frameworks calls build() from vite programmatically would assume it only performs one build. Frameworks like VitePress or Vitest will reuse the vite.config.js. Allowing a plugin to change its behavior of it is a bit risky for me.
I think multiple builds should be handled by upper-level frameworks to call Vite programmatically (multiple times at different timing), just like how we do it in many frameworks now. If we really want to rescue the CLI from Vite, I guess we could introduce a separate command like vite pack, but that would be a different story.

I'm not sure if vite pack is a good idea.
I'm afraid most users would confuse it with vite build, then we still need a mechanism to warn them to use the correct command. If that's the case, why not just tell them to use another CLI tool?

RFC by antfu: https://hackmd.io/WgkOsRmpT0e5ACJHc0Dh6Q

RFC here: https://github.com/vitejs/vite/discussions/9442 (solving the limitation of writeBundle closeBundle in general). I am still leaning to against multiple builds in vite build.

RFC summary: https://github.com/vitejs/vite/discussions/9442#discussioncomment-3303445.
New discussion for #9496 - Should $ vite build also build SSR?.


[Merged by Bors] - Fix CI

is it due to a regression in rust nightly, or is it something that we actually need to fix in Bevy?

regression but i'd be kind of surprised if it was fixed since it doesnt seem like a clear cut "bug"

bors r+

Discussion about this in the rust-lang repo: https://github.com/rust-lang/rust/issues/89352#issuecomment-1119673901
For now, waiting for a crater run to see the impact


Add new Gitub Action Workflow

The pipelines are failing, but not because of the pipeline but because of necessary changes.
This will be merged into the 2.0 branch and fixed there.


[FLINK-28419][table] Add runtime provider interface for full caching lookup + implement Periodic and Timed cache reload triggers

What is the purpose of the change
This pull request introduces new interfaces that allows to use Full cache as LookupFunctionProvider. Interface list:

FullCachingLookupProvider
CacheReloadTrigger

CacheReloadTrigger provides customizable way when to trigger cache reload operation. There are 2 built-in triggers:

PeriodicCacheReloadTrigger - cache is reloaded with fixed intervals without initial delay
TimedCacheReloadTrigger - cache is reloaded at specified time with fixed intervals multiples of one day

Also there are introduced common options for connectors that will support Full caching lookup join.
Brief change log

Add interfaces FullCachingLookupProvider and CacheReloadTrigger
Implement reload triggers PeriodicCacheReloadTrigger and TimedCacheReloadTrigger
Add common SQL options for Full caching lookup join

Verifying this change
This change added unit tests for the newly added PeriodicCacheReloadTrigger and TimedCacheReloadTrigger
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): yes
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? (yes)
If yes, how is the feature documented? (FLIP docs + JavaDocs)

@PatrickRen  Thanks for the review! I've made fixes according to your comments. Please look at the latest commit, when you will have time.

@PatrickRen I resolved your comments and rebased. Additionally I changed error messages and config descriptions, so they now correspond to the ones for partial caching. You can have a look. Do I need to run CI again before merge?

@SmirAlex Yeah we have to wait for a green CI run. It should be running now so let's wait for a while.

@flinkbot run azure

@PatrickRen There were multiple failed pipelines, but they were because of unrelated issues. Latest pipeline was successful - https://dev.azure.com/asmirnov1/Flink/_build/results?buildId=17&view=results

@PatrickRen thanks for the review! I've fixed last comments about javadoc.

Merged on master 5405239dec0884dff746129c73955c90f455c465

I would like to ask, as I have a scenario where Flink writes into Hudi. Due to the complexity of the SQL process, I want to turn the whole process into an SQL file. However, due to the latency of the insert operation, I want to delay the operation through Flink SQL statements. Is there such a statement that can implement the delay operation, for example, execute the next SQL statement only after 5 seconds?