Postgres 17 mergeInto with returning

Postgres 17 now supports MERGE INTO with RETURNING (which very handy to streamline queries and upsert records without writing multiple queries).
MERGE INTO heroes AS h
USING (VALUES ('Wade', 'Wilson', 'Deadpool')) AS v(first_name, last_name, hero_name)
ON h.hero_name = v.hero_name
WHEN MATCHED THEN
  UPDATE SET first_name = v.first_name, last_name = v.last_name
WHEN NOT MATCHED THEN
  INSERT (first_name, last_name, hero_name)
  VALUES (v.first_name, v.last_name, v.hero_name)
RETURNING merge_action(), *;

Is it possible to create the preceding query (taken from the Neon release note) with Kysely?

Hey 👋
Not yet.


Group frame distribution by device address

Device data nodes need to filter each frame by address before parsing frame contents. Because all data nodes in a workflow are operating in parallel, this means that naively each frame will be checked once by each data node.
This PR implements a more efficient distribution strategy, whereby the context task preemptively groups the frame sequence by device address and provides the sequence of groups to data nodes. With this strategy, each data node only needs to find the group with the right address at subscription time, and can then proceed to process all frames without the need for further tests.
In other words, this moves testing address complexity from O(n * m) to O(n) + O(m), where n is number of frames, and m is number of data nodes. Given that n is often in the order of a few thousands per second, this has the potential to result in significant speedups, even for a small number of data nodes.
Fixes #62

I tested with the following hardware

headstage-64

Streaming works fine
Turn off midstream and recovery is fine

headstage-np2.0beta

Streaming works fine
Turn off midstream and recovery is fine

Before merging, let me perform one more test: I notice hardware memory accumulation with BlockRead = 2048 on my computer when using npx 2.0 beta. I want to see if this the case with the old version.

Sounds good, if you have time you can also compare against JIT optimisation by running in Release mode without debugger (Ctrl+F5).

Interestingly, it seems like it might be a bit worse in terms of keeping up with data collection. Seeting block read to 2048 bytes, on my computer, makes it so that main is barely able to keep up with data production but there are periods of ~0 growth in memory usage. These are less frequent on issue-62 and growth seems more monotonic.
main:

issue-62:

However, this is a super noisy test for tons or reasons and really indicates that the system calls, which are occurring at the same rate in both scenarios are probably the issue. In fact, empirically, we have found that sometimes less efficient code is better able to keep up with data because the scheduler keeps in state closer the CPU. .e.g. a 10 kHz feedback loop with small data packets and no processing to speak of has a faster per frame round trip time on my hardware than a 1 kHz loop that does the same thing.

Sounds good, if you have time you can also compare against JIT optimisation by running in Release mode without debugger (Ctrl+F5).

Oops thats a good point

With optimizations:

Now issue-62 has a slight advantage. I think the take home above stands regardless of these noisy measurements and we should merge.

main:

Issue-62:


Greenkeeper/eslint plugin import 2.17.2

Pull Request Test Coverage Report for Build 124

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 123:
0.0%

Covered Lines:
4

Relevant Lines:
4

💛  - Coveralls


fix  064_builtins: @addWithOverflow() explanation

The last two examples do not overflow, because the
result is small enough. This was probably just a typing
error in the original explanation.

Is it really an oversight? I think the several lines show the process of adding 0101 to 1010 one by one. The two "YES!" show the overflow status of last two steps. At that time, the overflow has already happened and "Overflowed?" is "YES!".

@ziyi-yan I thought about that too, but in the context of the builtin @addWithOverflow function that does not make sense, because it returns a result per operation, not for several operations. Also afaik the flags of CPUs are also set for the last operation. Also @ratfactor wrote the original text and confirmed it was an oversight, so I think everything is alright :)

@ziyi-yan and @DerTee Yeah, thanks for the additional thoughts on this. I really wish I knew what I was originally intending with those lines. It's strange. I wonder if it might be even better just to remove them?

@ratfactor I actually think that your about counting a value up to and over the point where it overflows is a good idea. Removing the two lines that come after the overflow would help to not confuse people about the builtins exercise, but they might also come out with a false understanding of overflow.
The crux is that counting up a variable and exceeding its capacity overflows only in one single @addWithOverflow operation, but afterwards the variable stays overflowed even though the subsequent counting operations do not overflow. So there's a difference between a overflowing operation and an overflowed value. I don't know if it's worth teaching these finer details within the context of teaching Zig's builtins, though. Maybe introducing @as in this first exercise or one of the other builtins would be better?
Anyway, here's my shot at trying to make the @addWithOverflow part clearer:
    // Let's try it with a tiny 4-bit integer size to make it clear:
    var a: u4 = 0b1101;
    const b: u4 = 0b0001;
    const count: u4 = 5;
    var my_result: u4 = undefined;
    var overflowed: bool = undefined;

    // Let's count up and see when we get an overflow in a nice table:
    print("  a  |  b   | result | overflowed?\n", .{});
    print("----------------------------------\n", .{});
    var i: u4 = 0;
    while (i < count) : (i += 1) {
        overflowed = @addWithOverflow(u4, a, b, &my_result);

        // Check out our fancy formatting! b:0>4 means, "print
        // as a binary number, zero-pad right-aligned four digits."
        print("{b:0>4} + {b:0>4} =  {b:0>4}  | {}\n", .{ a, b, my_result, overflowed });

        // To make counting work, we store the result in variable a.
        a = my_result;
    }

    // Now we check the difference between the result we get with overflows
    // and the result we get without an overflow by using the same
    // starting value as variable 'a' plus the times we counted up.
    const expected_a: u8 = 0b00010010;
    print("Our overflowed a is {b:0>4}. Without overflow it would be {b:0>8}.\n", .{ a, expected_a });

    print("Furthermore, ", .{});

The full output would then look like this:
  a  |  b   | result | overflowed?
----------------------------------
1101 + 0001 =  1110  | false
1110 + 0001 =  1111  | false
1111 + 0001 =  0000  | true
0000 + 0001 =  0001  | false
0001 + 0001 =  0010  | false
Our overflowed a is 0010. Without overflow it would be 00010010.
Furthermore, 11110000 backwards is 00001111.

I'm not sure if it's really better, but I'm trying to be as constructive as I can and at least propose some solution.

@DerTee Yeah, I see where you're going with that.  It would be really nice to see the moment where the value overflowed!
I've tried to keep the correct output of Ziglings exercises short to make them easy to check for correctness (at least partially inspired by the single numeric answers to exercises in https://projecteuler.net/). Originally, I was shooting for single line output, but that was too limiting.
I'll have to think about this. The table of output would be really nice.

Still thinking about this. I love the table idea, but would also like to avoid such a large "answer" output.  Is there some way to display this same information in a compact way without losing too much clarity?

@ratfactor Probably the best way is to not generate the table in code, but simply put the output table in the comments, just like you did originally. I have a draft we can have a look at. I'll push it into this PR as soon as I figure out the github stuff (I screwed something up locally).

@DerTee Sorry for the delay getting back to you on this. I like what you've got! Yeah, do please create a new PR. I'm sure we can link the two somehow by mentioned this one in that one.


badwolf theme: make inactive status line stand out more

When using horizontal splits with the badwolf theme, the statuslines of inactive windows are hard to see. To improve the window boundry's visibility, I inverted the fg and bg colours.

this is what i'm seeing....the text is blended and you can't even see it anymore....

Apologies, I only tested in GVim. With the latest commit added (changing the last s:N3 to s:N2 too) it works in the console too.

let's try this out and see if other badwolf users like it or not :sunglasses:

Thanks for the merge, and for a great plug-in. :)


Fix code scanning alert - Clear-text logging of sensitive information

Tracking issue for:

[x] https://github.com/lithika-damnod/chatium/security/code-scanning/1

This issue has been resolved in commit: 14819d9c0fefbe1418b68823efb2fd9175e5340f
👍


Update _collection_abc.py Cpython v3.9.7

The failing tests looks like to be resolved with #3453

#3453 is just merged - which resolves new errors. Could you rebase this PR once again?


Unreadable white coloring on hover while on dark mode

In dark mode, the diff and action are unreadable while hover over them,

Resolved in 0.158.0

Yeah, closing this out.


hiveutil: print validation error for create-cluster

When there is a validation error running hiveutil create-cluster, the command exits without an output to the user. These changes log the validation error and exit with a non-zero exit code.

/lgtm


Nodes page and scaling to large number of workers

Nodes page is useful, but needs to be more scaleable to support larger number of nodes... hundreds if not possibly 1000s of worker-nodes.  A tabular list-view that listed information such as:
hostname
number of jobs currently executing
fuel bars for:
disk
cpu
ram
% success rate of the node over last 24, 12, 6 hours.
The fuel-bars would represent utilization that particular worker is according to the number and type of jobs currently assigned, subtracted from the available resources of the node.  We can do that right?  That's not too much to ask (I mean of the API calls and UI threads) is it?
Clicking on any particular worker-node line would take you to the "currently running" page filtered by that node name.  So a user could see exactly what that worker was doing.

Dumplicate of #68

Clicking on any particular node line could take you to a node detail page which (among other things) could have the running  job executions.

This is actually not a dupe. The node detail page is for displaying a single node. This issue talks about the page display all nodes (or an overview of nodes). I would recommend re-opening. :)

Can't we just factor all this into one item?  If we capture the "complete" user story in #68 then we shouldn't really need #69...  Now, for a specific bug report or a feature "tweak" then it makes sense to be as specific as possible, but we're talking about a more "fundamental rethink" for the whole nodes page concept.
But I can go either way.
-C.

On Mar 11, 2016, at 2:52 PM, Derick Faller<EMAIL_ADDRESS>wrote:
This is actually not a dupe. The node detail page is for displaying a single node. This issue talks about the page display all nodes (or an overview of nodes). I would recommend re-opening. :)
—
Reply to this email directly or view it on GitHub.


Incorporate missing stuff from cmd2 related to tab-completion results

This should fix a few bugs related to incorrect tab-completion results.

I doubt anyone was using these newer settings from cmd2 yet, but it is prudent that we add them here.


p tags cannot contain div tags

Hey,
I was trying to use react-image-crop but it gave me this error:
Warning: validateDOMNesting(...):  cannot appear as a descendant of . See App > p > ... > ReactCrop > div.
steps to reproduce: use create-react-app with react-image-crop
Greetings,
Mika

Hi,
It's advising that you shouldn't put a div in a p, ReactCrop has divs in it
and you put it in a paragraph tag
On Sat, 9 Sep 2017 at 11:52, mikat<EMAIL_ADDRESS>wrote:

Hey,
I was trying to use react-image-crop but it gave me this error:
Warning: validateDOMNesting(...):
cannot appear as a descendant of
. See App > p > ... > ReactCrop > div.
Greetings,
Mika
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/DominicTobias/react-image-crop/issues/113, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAuZ-hqKBHArqs-SXkdLlmFGOQQemPkjks5sgm3TgaJpZM4PR9cO
.

oh wait yes it put it in the main element of the demo which is a p tag, thanks for the reply it works now :)


Why is not possible to recall sendRegistrationIdToBackend()

Hi guys! First of all, thanks for your amazing library. It will save lot of my time.
I was wondering why not to have some way to recall this sendRegistrationIdToBackend method.
I mean.. I know that it's called in the first install of your app once you register by the first time with google, and I think (I'm not really sure, please clarify this) that it's called again once the app is updated.

I know that I can handle it easily, but I think it would be easier to be able to call this method again..
what do you think?
Thanks a lot again!

Good question. We will investigate this (with higher priority).

Hello, @josefrvaldes , I suggest you check the methods boolean EasyGcm.isRegistered(Context context) and String EasyGcm.getRegistrationId(Context context). Those two should allow you good access to the registrationID as well as information whether the registration already occured (for which the sendRegistrationIdToBackend method serves)

Yes, I know that I can use those methods, in fact I'm already using it. But it was just a suggestion.
I will take a look at that GcmListener. It looks interesting.
Thanks a lot :)

@josefrvaldes How would you suggest the workflow to be improved? The library itself does not have any way to know if the registration process between the application and the backend failed. I can only imagine the GcmListener method I mentioned to you in previous post to be invoked manually from within your app if you detect a failed backend registration.

As I still haven't used GcmListener I can't answer you now about it.
But for example, right now what I'm doing is to have my own method called registerToBackend() that is called from inside library's sendRegistrationIdToBackend(). And after that, if I detect that there was some error during registration, I may call my registerToBackend() method again from anywhere.
There is no problem in doing it like this, but that's why I was suggesting that maybe it could be helpful if there was the option to call something like EasyGcm.resendRegistrationIdToBackend()
Or maybe you could do sendRegistrationIdToBackend(String regId) return true or false depending on the success/error of the transaction and it would trigger something like onRegistrationOK() or onRegistrationError().
That last one it's maybe more difficult and needs to be studied. But I think the first suggestion could be fine.
Thanks a lot again for your answers and thanks again for this amazing library! :)

Remaking sendRegistrationToBackend(String regId) to return boolean values for the library to know if registration was succesfull or not is not a good idea. The library would then need a mechanism to retry the registration and handle error states, while those can be very specific based on the application architecture. The result of the backend registration - successful or unsuccessful registration to backend is only known to the application and should not be a concern of the library (you would end up having a single lib - easygcm handling 2 responsibilities - GCM + backend registration while having the backend registration actually split to two places).
As for the EasyGcm.resendRegistrationToBackend() I think this might be a good idea, although it would need to handle the state when it is called before the actual registration occured (return an error value, special case object or not invoke sendRegistrationToBackend(regId) at all?). Currently the behaviour can be simulated using:
EasyGcm.getGcmListener(context).sendRegistrationIdToBackend(EasyGcm.getRegistrationId()); to which I would also add an if statement with EasyGcm.isRegistered() to handle error states.

Yes, I totally understand your first matter.
And about the second matter, if you are currently able to call EasyGcm.getGcmListener(context).sendRegistrationIdToBackend(EasyGcm.getRegistrationId()); maybe that is all we need and it's not necessary to implement that EasyGcm.resendRegistrationToBackend() anymore.
Now the only thing that I suggest is to write that solution in the README file :P
Thanks again!

If you test the solution and it works, please write me here so I can close the issue.
We will add the info to the readme as well as consider adding a resendRegistrationIdToBackend() convenience method in the future release :)
Good luck with your app development :)

I just tried this EasyGcm.getGcmListener(context).sendRegistrationIdToBackend(EasyGcm.getRegistrationId()); and it doesn't work. There is no such method as getGcmListener. There is a setGcmListener but not get.

I see. Sorry, I overlooked the fact, that getGcmListener() is a non-static public method and cannot be accessed. I will ensure a new version with EasyGcm.resendRegistrationIdToBackend() convenience method added comes out in a few days.

OK! Thanks a lot!! :)

Added in 1.6.2

Perfect! thanks a lot! :+1: :+1: :+1:


First load of fragment removes fragment

Problem description
When loading https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact in FF 53 on macOS, the page briefly loads some location on the page and then immediately reloads, removes the fragment, and scrolls to the top of the page.
Problem location
https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact at least and probably other, similar URLs.

Once on the page, if you paste the same URL (with fragment) into the address bar and press Enter, the page scrolls to the correct location.

--- docs.js     2017-11-02 10:38:48.187751200 -0700
+++ docs.js     2017-11-02 10:37:40.836611500 -0700
@@ -10,7 +10,6 @@
 if (current[0]) {
     if (sidebarObj) {
       current[0].scrollIntoView(true);
-      body[0].scrollIntoView(true);
     }
     // library hack
     if (document.location.pathname.indexOf("/samples/") > -1){

More generally, just about all the JS I'm seeing is really convoluted.
Why do you need to be playing with the scroll at all? Hopefully it's not just to counteract your fixed header being over your h1-h6 text headers. To fix that you need only add some padding to those headers (or whichever element has the id on it)
h1, h2, h3, h4, h5, h6 { padding-top: 50px; margin-top: -50px !important; }

Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks!


Improve output logs

Improvement of output logs:
- A general output log for MIDAS called midas.out. This will contain a 1st section with general information (selected algorithm and problem), a 2nd section with algorithm specific prints, and a 3rd section with some general conclusions (e.g. optimal solution).
- An algorithm specific structured output log (e.g. results by generation for GA)
- An algorithm agnostic dump of all calculations for debugging and other usage.

midas.out should report the RNG seed used. Can this be fetched from the random library?


Objects of array in computed is empty?

Objects of array in computed is empty:

Objects of array in state is not empty:

Code:

Hey @heloisasvl,
I know it's a little bit tricky, because your code is pretty complex, but it would be really awesome if you could provide a reduced test case on JSFiddle. You can take a look at this JSFiddle to see how to set up vuex-map-fields in JSFiddle. Thanks!
(I'll look into this eventually, but if you can provide a JSFiddle, helping you takes me less time and thus will be faster =))

@maoberlehner You can see the issue here: https://codesandbox.io/s/nw79l9199p

Ohh, took me a while to get your point 😅
Thank you for linking to a CodeSandbox, this made it a lot easier for me 👍
That's an interesting behavior which stems from the fact that addresses in the CodeSandbox example is not really an Array. addresses is an Object with a get() function which returns an Array (see https://vuejs.org/v2/guide/computed.html#Computed-Setter for reference). Thus it behaves like it does.
May I ask what you're trying to achieve where this is a problem?
One way around this might be to additionally use mapState to map a read only reference to the addresses Array.

@maoberlehner In my case there was isEmpty() function of Lodash library which didn't work so I've replaced it to checking length property for 0. So that is not a big issue. Another minor issue is that Vue Dev Tools doesn't show the content of the variable.

I think it can be easily solved setting enumerable: true in the 3rd parameter of defineProperty() here: https://github.com/maoberlehner/vuex-map-fields/blob/master/src/index.js#L77


Handle eperm errors windows

This is a fork based on the work of @codeimpossible as the base of PR #13 and with the comments as given by @iarna on that same PR.
I've implemented a MD5 hash check to verify that the destination file is indeed the same file as the tmp file on Windows when the EPERM error is occurring.
Please note that this is my first PR on a project of this type, please let me know if that I did anything wrong or if that I need to improve on some level.

We avoid using md5 because some folks regulatory compliance checks will fail if md5 is used anywhere even in places where the cryptographic properties of the hash don't matter. (They use software to verify this and don't like exceptions.)
Could you do this using something like sha256 from crypto?

I integrated Crypto in favor of MD5, also fixed an issue with the tmp file not being removed if the copy failed and the target file is the same as the tmp file.

Any idea when this PR will get merged in? A lot of windows developers are running into this issue.
Thanks!

@iarna thanks for the feedback on the code, i don't think i can update this PR so I'm happy if you're cool with you fixing it ;)
I'll close out the other PR too since it's not needed anymore.

@codeimpossible Oh yeah, good point =D

Out of curiosity, what's the status of this pull request?  We've been running into quite a few issues with this in our development.

Is this going to be merged?

@wvankuipers just a note - I've been investigating this as a fix for https://github.com/npm/npm/issues/12059#issuecomment-244663459, as stated in the comments there. Using this branch of fs-write-stream-atomic and a current version of npm (4.1.1) does not solve my EPERM: operation not permitted, rename problem in Windows 7.

@mateodelnorte The issue you are referring to has multiple different issues combined. some of these issues will be corrected by this PR, but others are from package that don't use fs-write-stream-atomic so they will not be fixed. My guess is that other fs packages have the same issue, those should be fixed separately.

How can we get this merged? Are there any workaround using this PR? Is building our own node the only way?

@domenkozar No clue about if this is going to be merged, there seems to be a radio silence from @iarna regarding this issue 😞

I've had success updating to npm > 4, which made those errors disappear. I
think I saw something in the changelogs about that.
On Feb 7, 2017 1:31 PM, "W. van Kuipers"<EMAIL_ADDRESS>wrote:

@domenkozar https://github.com/domenkozar No clue about if this is
going to be merged, there seems to be a radio silence from @iarna
https://github.com/iarna regarding this issue 😞
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/npm/fs-write-stream-atomic/pull/14#issuecomment-278095952,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqj3Q7lYHbwSy547XVVWGPQqHUmrG_cks5raLhlgaJpZM4JVR4c
.

Thanks for the tip!

Ok, so here's what I've done:
I rewrote it a bit to read the file hashes using streams (as we don't know how big these files are, possibly tens or hundreds of megabytes).
I switched to sha-512 (which is faster on 64 bit systems).
I squashed all the commits down to one.
This is now merged as 2f51136.


Virtual Keys

Hi, In some games is not possible to modify their gamepad button settings, in that case I wanted to make custom keys for the keys that isn't available on Nimbus controller at Virtual Keys. So I've noticed that both LTrigger and RTrigger isn't available to use to create Virtual Keys neither both joysticks, can you add them to list of buttons at Virtual Keys? If it's not possible to add joysticks, can you please just add Triggers?

Adding buttons only was easiest solution to the virtual keys problem.
In the future I will implement axis support to the "Virtual Keys".

Hello Michał, I am still waiting for Trigger buttons to be supported by Virtual assignment section.
Please make a small update for your great application.


Game tick information

Features a number of tools to help track time for tick manipulation skilling methods, lets you track the time spent on the current tile, and display a cycle of game ticks. Also lets you mark tiles as start locations to track 'laps' on any content.

Don't open new pull requests to fix issues, just push the changed commit hash to this PR

I'm not sure what I've done wrong here, this is my first time trying to contribute code to any project, and I see this failed check which I think is caused by dependency verification. I'm not sure how to resolve this, I only used imports that I saw in other plugins.

Tip: you can actually read the error to see what the problem is and which packages failed dependency verification. You can then remove them from i.a. your build.gradle

Thanks, figured out the issue. I also removed the chat commands, I'd just been using them for debugging during development anyway.


[Request] Power Button State

I'm wondering if it is possible to get the power button state at all?
I noticed in the AXP2101_Class for the unified library that there was functions like "isPekeyShortPressIrq()" and was curious if this is for the button and if so can it be added to the library, or is there a work around at all?

Hello, @Dreadnoise
You can use M5.BtnPWR.wasClicked() and M5.BtnPWR.wasHold()


Implement flake8-future-annotations FA100

This PR tackles the first part of #3072, which is to raise a lint error when a rewrite-able type is used without from __future__ import annotations present.
Test cases taken from: https://github.com/TylerYep/flake8-future-annotations
Some of the test cases I added (prefixed by no_future) do not raise lint warnings now (as expected), but will raise lint warnings once FA102 is implemented. I am adding them to ensure they do not raise extraneous errors to begin with.
This lint rule also found some available fixes in scripts/check_ecosystem.py, which tells me there's some value to having this around :)
The next two PRs will add the autofix functionality for FA100 and FA101 and/or FA102. Thanks for the review!

I'm not sure why tests are failing - running cargo test locally passes cleanly for me.
Any idea @charliermarsh ?

@TylerYep - Just needed to merge, we recently hit a limit on a fixed-size vector that stores all the rules and it had to be increased.

I went back to my original plugin and remembered why DefaultDict and Deque were originally included in FA100:
The main goal of this plugin is to signal to users when a type annotation could be rewritten in a more concise way when from __future__ import annotations is added.

This code could be simplified (and is currently autofixed by Pyupgrade):

from typing import List, Optional, Union

a: List[int] = []
b: Optional[Union[int, str]] = None

from __future__ import annotations

a: list[int] = []
b: int | str | None = None

This code could be simplified (but is not currently autofixed by Pyupgrade):

from collections import defaultdict, deque
from typing import DefaultDict, Deque

a: DefaultDict[int] = defaultdict(int)
b: Deque[int] = deque()

from __future__ import annotations

from collections import defaultdict, deque

a: defaultdict[int] = defaultdict(int)
b: deque[int] = deque()

https://github.com/asottile/pyupgrade/issues/799 provides context on why collection types are not rewritten using Pyupgrade (import aliasing is hard). It might be possible to extend the autofix functionality to rewrite all of them correctly, but that is out of scope for now.
Afaik, DefaultDict and Deque are the only two code changes included in PEP585, improved using from __future__ import annotations, but not autofixed by Pyupgrade.

This code cannot be simplified, but can use a different import. These cases are not intended to be raised by this flake8 rule because the type annotation doesn't need to be changed by adding from __future__ import annotations:

from typing import AsyncIterator, Mapping

a: Mapping[int, str] = {}
b: AsyncIterator = ...

from collections.abc import AsyncIterator, Mapping

a: Mapping[int, str] = {}
b: AsyncIterator = ...

My view is that both 1 and 2 should be raised by this plugin, but not 3, because the code itself is not improved by adding from __future__ import annotations.
If this makes more sense to you, we can revert 4373751.

Will merge this after cutting the release.

Will merge this after cutting the release.

I thought it might be worth flagging that the changes to the ecosystem check seem to be causing it to error. I don't have time to investigate now but thought it would be worth saying something before this is merged.

What is the error?

What is the error? I see check_ecosystem imports Self, which must mean it's running on Python 3.11+, so none of my changes should impact it.

Error in the ecosystem check above:
'async_generator' object does not support the asynchronous context manager protocol

Was that caused by removing asynccontextmanager? It was an unused import that pre-commit told me to remove

I made a few changes here that I think are improvements based on some of the capabilities we have in Ruff, but if you disagree, just let me know and we can of course discuss further -- want to merge to keep momentum.

I removed the diagnostics that trigger on-import, and instead, I'm more closely following our pyupgrade rules. We flag all usages, regardless of whether the user does import typing or from typing import List -- when the user writes typing.List or List, we resolve it to typing.List. So it's always sufficient to just flag usages, given that we have enough binding tracking and semantic analysis to resolve those usages, regardless of how they're imported.
These rules now only flag if your minimum version is below Python 3.9 (or Python 3.10, for Optional and Union), since adding __future__ on those versions has no effect with regards to simplifying the imports. (You can already use the standard library generics on those versions.)
We weren't flagging Optional or Union, so I added that too.


Unable to upload files on multiple input with preloaded files

Hi, I'm trying to use the allowMultiple feature but I'm unable to make it work properly.
When there's no files on start it works fine, but when I initialize the input with already uploaded files with this config:
options:
{
  allowMultiple: true,
  server: {
    process: myProcessHandler,
    revert: myRevertHandler,
    restore: myRestoreHandler,
    load: myLoadHandler
  }
}

files:
[
  {
    source: 'myfile.pdf',
    options: {
      type: 'local'
    }
  }
]

And try to add another file, the process event isn't triggered and file doesn't get uploaded.
I'm currently using filepond v1.7.1 and ngx-filepond
Thanks for your time

Is the myfile.pdf file correctly loaded via the server load endpoint?

Hi,
yes, the preloaded files get loaded correctly (or at least I think so). I can even remove them.
Here is the events log:

When I try to upload another file I get this events:

While when there is no preloaded files the output is something like this:

The process never starts when there are some preloaded files

@aitorllj93 I'm not sure what's going on. I just tested with 5 local files, adding a new file correctly runs the process method. Do you have a public test case?

Will close for now.

I'm also having trouble uploading multiple files on Vue with allow-multiple set to true.

@Carmezim That's so weird.
Some questions:

Does renaming to allowMultiple do anything?
Are you using Vue-CLI?
Can you create a public test case?
Does it only happen when setting the files array?

@Carmezim I've just uploaded a new version of FilePond which will probably fix the issue in Vue


Adjusted compile command needed after upgrade to Mastodon v4.2.0

Hi :)
I upgraded our Mastodon instance tonight from 4.1.9 to 4.2.0 and also updated TangerineUI to 1.9-pre.
Since the config/themes.yml file changed, I re-added the TangerineUI themes there. When running RAILS_ENV=production bundle exec rails assets:precompile it simply told me: Everything's up-to-date. Nothing to do
However, restarting mastodon-web.service afterwards resulted in FATALs and made the webinterface unavailable:
Sep 21 21:51:23 mastodon bundle[30968]: F, [2023-09-21T21:51:23.136803 #30968] FATAL -- : [d2685765-a7ff-47a6-838e-16da87e4d759]
Sep 21 21:51:23 mastodon bundle[30968]: [d2685765-a7ff-47a6-838e-16da87e4d759] ActionView::Template::Error (Webpacker can't find tangerineui-purple.css in /home/mastodon/live/public/packs/manifest.json.

While searching for a solution (pasting the error message into a search engine), I stumbled upon this issue here. I then tried:
RAILS_ENV=production bundle exec rails assets:clobber assets:precompile

This worked fine :) I'm by no means a Ruby/Rails guy and I'm a bit out of my depth here, but I understand assets:clobber removes compiled assets first, so we have a clean slate and can then precompile anew. If I'm not completely wrong here, maybe this could be added to the README?

Oh, I'm really sorry, I should have read https://github.com/nileane/TangerineUI-for-Mastodon/issues/53 first 🤦♂
I guess it's the same issue.

Hi!
I'm definitely not a Ruby/Rails girl either, so I'm willing to trust you on this if perhaps you (or anyone else) can get confirmation that adding assets:clobber to the command can work in every case!

I haven't received any new reports regarding this issue, so I'm going to close it for now. I will reopen it if anything similar happens again and requires a change in the README instructions.


Add scientific linux support

Add scientific linux which is compatible with rhel

thank you so much for this pull request<EMAIL_ADDRESS>


Update Requirements

On requirements feature of editing a post is not included, add this feature.

Reopened since an update for IA's editing is also required


Add ImGui Dialogs

Download Demo AppImage for Linux to see it in action:
https://drive.google.com/file/d/1fcFn28AFrmHoq58L1l5t1t4mVvJrFVSV/view?usp=share_link

I still don't have access to my windows, macOS, or Raspberry Pi, so the only platform I have built the new version of libfiledialogs for is x86_64 Ubuntu. Ubuntu needs the deps:
sudo apt-get install -y libsdl2-dev libgtk-3-dev libglib2.0-dev

Windows needs Visual Studio to build. Note building with MinGW due to a bug with g++ will not work with Chinese Characters so Visual Studio's compiler is required.
macOS needs to be built with the build.sh script from the command line. Needs Xcode, Xcode command line tools, and MacPorts. With MacPorts you need to install libsdl2 with the +universal flag passed to it via the command line:
sudo port install libsdl2 +universal
# ./build.sh

Please @chenxi050402 consider building these for me on Window and macOS, or even RPi if you want, this will be a huge benefit to myself and for this project in the case of the Windows and macOS builds.
Then you can commit those files here, since I gave maintainers write access. :)

the non-file dialogs (show_message(), show_question(), and show_question_ext()) flicker their graphics context back in forth from drawing their content to drawing all solid black. This has now been fixed with my libfiledialogs extension but i still need to commit those fixes to this repository. Please be patient and don't merge this until i have done so.

hey time! would you like me to build them for windows?.

hey time! would you like me to build them for windows?.

Sure! Thank you!
Source code here:
https://github.com/time-killer-games/libfiledialogs
Requires Visual Studio 2019 or later.

i have visual studio 2022. could you also link to instructions on how to build using visual studio. as i main vscode and i have never once built for windows

File -> Open. Select *.sln File.
Select "Debug" Dropdown Box and change it to Release
Build solution.
Select "x86" Dropdown Box and change it to x64
Build solution.

I can't remember whether onbs relies on an older version of gms or not which is why i need both x86 and x64 dll to play it safe and make sure i have what i need. But i only need one or the other, not sure which/ I'll find out from Ben.

also it's not the dll i need, actually its the exe it builds, for clarification.

@charlie-sans It's not the dll i need, actually it's the exe it builds, for clarification.

File -> Open. Select *.sln File. It is in libfiledialogs/filedialogs/filedialogs.sln.
Select "Debug" Dropdown Box and change it to Release, (unless it's already set to Release).
Select "x86" Dropdown Box and change it to x64, (unless it's already set to x64).
Build solution. The file wll be in libfiledialogs/filedialogs/x64/Release.

@Bentroen @chenxi050402 this one should be ready for review, and if you find any issues i still haven't noticed, please let me know!

The file dialogues for Windows are also built by the help of me. I thank
you for letting me be of assistance.
On Sat, 25 Mar 2023, 7:14 am Samuel Venable, @.***>
wrote:

@Bentroen https://github.com/Bentroen @chenxi050402
https://github.com/chenxi050402 this one should be ready for review,
and if you find any issues i still haven't noticed, please let me know!
—
Reply to this email directly, view it on GitHub
https://github.com/OpenNBS/OpenNoteBlockStudio/pull/385#issuecomment-1483356149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4EUQ4MBDRK5VCVTJ4RIUK3W5X6CPANCNFSM6AAAAAAV6B6VAU
.
You are receiving this because you were mentioned.Message ID:
@.***>


Do not raise delete trigger event on an update of a rule

Turns out the check to validate if delete_by_reference actually deleted a TriggerDB was missing. Check brought in therefore should now fix the regression.

+1


Suggesting changing the project name to something else

Being a proponent of free and open-source software, I absolutely love the project and the fact that it lets me play (read, grind through) my favourite videogame with smoother animations and framerates and does not let the publishers limit the framerate even when I have a desktop video gaming setup that is more than capable of performing great. The 1121 stars on GitHub (at the time of creating this issue ticket) makes it more than evident that this project was successful in doing what the original developers did not even consider adding to the video game even after countless times telling them about this in the in-game surveys and a variety of forums.
That being said - I do feel concerned about the project and about its contributors. The publishers being a huge corporate body will have no mercy towards smaller developers who are introducing a quality-of-life feature to the game that they themselves should have implemented in the first place. We know that this application is harmless and does not do anything that would directly affect the publisher's revenue but chances are that they do not really care. As a result, this project and the contributors might get severely affected by possible lawsuits or cease/desist orders that they might send the way of the original author, forcing the project's sunset.
Like many other projects that are built for this videogame, I think that we should rename this project to some name that is somewhat relevant to the purpose of the application and yet, makes it harder for the publisher's management to be able to track it.  I understand that it might make it difficult for the users to find this application though.
Here are some suggestions.

Option A animegame-framerate-unlocker
Option B framerate-unlocker
Option C animegame-framerate-enhancer
Option D framerate-enhancer
Option E animegame-experience-enhancer
Option F experience-enhancer

I have added additional suggestions that do not include the word "unlocker" as it might be perceived as intrusive to the in-game monetization system by the publisher's management and they might assume that the application lets folks obtain premium items in the videogame without having to pay the necessary monetary amount for the same. That being said - feel free to take them (or not) but do consider protecting this project from the evil eyes of the videogame publishers. I am also interested to hear what the user community feels about this proposal.

IMO it's unnecessary.
First, it will break all existing links out there on the internet. Second, I can assure you that they do not care about this tool, not based on "how long it has existed" or "I haven't been banned in xxx days". I can't say why, but I can be sure they won't ban anyone from using this.

I would like to think that as well but that does not necessarily seems to be the case. As evident with the v3.7 release https://github.com/34736384/genshin-fps-unlock/issues/145, the memory pattern for the framerate limit was moved - necessitating you to provide an update for the application. I am not sure if they did it as a response to the application but assuming the worst situation helps us stay afloat.
It might be that they moved the memory pattern only slightly to see if either this application is still updated as a response to that or if you are able to reverse engineer their changes so that they can introduce even more protection features down the line. It really helps us to be extra careful before they start locking down but then again I will let you decide.

At this point i think apple is paying for exclusive 120 fps support.

IMO it's unnecessary.
First, it will break all existing links out there on the internet. Second, I can assure you that they do not care about this tool, not based on "how long it has existed" or "I haven't been banned in xxx days". I can't say why, but I can be sure they won't ban anyone from using this.

To address the point about the possible breaking of existing links - GitHub sets automatic redirects for the links with the older project name to the ones with the newer project name. Take, for instance, I maintain this project that lets you install NVIDIA drivers easily on Fedora Linux and it was called nvidia-auto-installer-for-fedora before with the link https://github.com/t0xic0der/nvidia-auto-installer-for-fedora but now the project is renamed to nvidia-auto-installer-for-fedora-linux and clicking on the previous link would still lead you to the correct location and not break the link.

it's not directed toward fps unlock, it's common for the pattern to change if they have made modifications to the engine

That's the best-case scenario. As their codebase is not open-source, we do not know for a fact if this was an attempt to gauge your capability of reworking the application to suit the newer memory pattern, to check your responsiveness to the project repository (owing to the fact that the previous release of v2.0.0 was made over a year ago) or if it was a normal modification to the engine as you mentioned. I would like to believe that they are modifying their engine to allow for a bigger asset control when the next region drops in the videogame update v4.0 but I cannot say that for sure.
All I am going to say is - It really helps to be protective all the time instead of being so as a response to something bad that the publishers might end up doing.

Having a different name to the project might cause confusion at a single glance but it might help to keep the project alive in case of any involvement from publishers.

I totally agree with what @t0xic0der is suggesting, this project needs some new name which does not explicitly mentions the "animegame" to avoid being railed by legal team at the animegame. Might I even suggest more things to do the logo in application can be changed to something which does not have same logo as animegame, the company might file Cease and Desist order against developers, and them being corporate giant as of now won't help your case, staying low and hidden is the best option as of now there are other animegame mods which does not mention name once but are accessible to people nonetheless. Having precautionary measures are always better than facing potential legal consequences later on.

IMO it's unnecessary.
First, it will break all existing links out there on the internet. Second, I can assure you that they do not care about this tool, not based on "how long it has existed" or "I haven't been banned in xxx days". I can't say why, but I can be sure they won't ban anyone from using this.

To address the point about the possible breaking of existing links - GitHub sets automatic redirects for the links with the older project name to the ones with the newer project name. Take, for instance, I maintain this project that lets you install NVIDIA drivers easily on Fedora Linux and it was called nvidia-auto-installer-for-fedora before with the link https://github.com/t0xic0der/nvidia-auto-installer-for-fedora but now the project is renamed to nvidia-auto-installer-for-fedora-linux and clicking on the previous link would still lead you to the correct location and not break the link.

it's not directed toward fps unlock, it's common for the pattern to change if they have made modifications to the engine

That's the best-case scenario. As their codebase is not open-source, we do not know for a fact if this was an attempt to gauge your capability of reworking the application to suit the newer memory pattern, to check your responsiveness to the project repository (owing to the fact that the previous release of v2.0.0 was made over a year ago) or if it was a normal modification to the engine as you mentioned. I would like to believe that they are modifying their engine to allow for a bigger asset control when the next region drops in the videogame update v4.0 but I cannot say that for sure.
All I am going to say is - It really helps to be protective all the time instead of being so as a response to something bad that the publishers might end up doing.

Again, there is no need to worry. Changing the repo name will not prevent mihoyo from tracking it. It is completely unnecessary. They are aware of this repo from the beginning, they don't care, and no one will be banned from using it.

I totally agree with what @t0xic0der is suggesting, this project needs some new name which does not explicitly mentions the "animegame" to avoid being railed by legal team at the animegame. Might I even suggest more things to do the logo in application can be changed to something which does not have same logo as animegame, the company might file Cease and Desist order against developers, and them being corporate giant as of now won't help your case, staying low and hidden is the best option as of now there are other animegame mods which does not mention name once but are accessible to people nonetheless. Having precautionary measures are always better than facing potential legal consequences later on.

There won't be any legal consequences. This tool does not hurt their revenue, it's not a cheat. The worse thing it can happen is just a DMCA.


Image tooltip

I modified the image module to allow users setting tooltips for image modules with scripts.
Hope there's someone can help me review this.
Thanks!

Hi @Alexays,
It's been a long while since I created this PR.
Have you taken a look? Is there anything I can help?

Sorry for the delay, LGTM!
Thanks again :)

Can you just update the Github wiki?

Can you just update the Github wiki?

No problem.


Add support for qqPath when choosing folder in dialog in Chrome

FineUploader currently includes qqPath in file parameters when dropping folder in Chrome. However, when a folder is added using a folder selection dialog, the qqPath parameter isn't available.
Accroding to my tests it is possible to read the full file path in this case from the webkitRelativePath file property. Could you please implement saving this data in the qqPath parameter for using in event handlers and requests to server?

I was hesitant to expose the ability to upload folders via the file chooser, since this is generally a bad idea due to the fact that the UI thread can lock up for long periods of time and cause the browser to crash. With this in mind, I don't forsee adding any further enhancements to support this workflow. You can always access the underlying File via the getFile API method.


Update guides & documentation on all supported Governance Actions

Guides & documentation should be updated along with adding support for all Governance Actions, be it by rendering only or allowing submission too.

There is currently no documentation pages on any Governance Actions. I am working on a new and better structure for the guides. Here is a tree view of where the new pages would live (the green branch)

This is currently blocked while I await a 'dev' copy of the guides to work on. I need this because of the major changes to the structure needed. I've asked @l-br1 on Slack to make available a temporary dev guides url so I can proceed without breaking anything.

Here is the existing and proposed navigation for GitBook:

This is done in guides release "#56 - Add all Gov Actions"
Cannot publish this yet, as the other changes to the structure - as outlined above - need to be added as well.

This is finished, but I am blocked as I don't have merge access anymore. I need the priviliges restored to publish this. This also blocks #2253

Done and awaiting review and publishing by @l-br1

Merged in to live Guides. There will be broken links. These will be in a new issue.


Version of latest docker build

We wanted to use the latest version of the image of your black. But that image is running 19.3b0 which is not the latest version when u install black locally.
When trying to build our own version we encountered a problem with the installation. You first need to add:
RUN apk add --no-cache --update gcc build-base

So the Dockerfile would look like this:
FROM python:3-alpine

LABEL io.whalebrew.name 'black'
LABEL io.whalebrew.config.working_dir '/workdir'
WORKDIR /workdir

RUN apk add --no-cache --update gcc build-base
RUN pip install --upgrade black

ENTRYPOINT ["black"]
CMD ["--help"]

After building this you have the newest version of black at your disposal :+1:

I've implemented your idea into the following PR: https://github.com/Unibeautify/docker-beautifiers/pull/52


Progress dialog appearing with white background in lollipop

The dialog works fine with kitkat. But with lollipop it comes with the default white background.

Thanks, I'll take a look into it once I have some free time.

Well, I got the solution.
We just have to add
getWindow().setBackgroundDrawable(new ColorDrawable(android.graphics.Color.TRANSPARENT));
before setContentView().


Weather "No location" on first start

This bug only appears when you've just turned on your computer and started the bot in a Docker container. However it does not appear with 100% probability.
I do try to handle this bug, but it is very difficult.
For now I am always trying to turn on a bash -x option with the first start of the bot to watch what's going on at the moment.

I think this is a bug in API of http://worldweatheronline.com/
After long break in work (~8h), first request from this site just return an empty answer, but in the next one all works fine
Now I'm thinking about change the weather API to another one


Auth - Create User

Create a user in the database once they have successfully signed up through Github.

Looks good! Moving to complete.


Item Descriptions HUD stops showing after a period of time

After a certain period of time, item descriptions will stop popping up.

^^Before^^

^^After^^

This has been fixed in dev, by checking the following fields in the default preset for moreHUD MCM. What was happening, is that after changing this MCM setting automatically, the setting wouldn't actually apply until a save reload or a door is entered. I quite like effect descriptions, so this will be enabled permanently.
Target Data tab

"Show Ingredient Effects"
"Show Other EffectS"


Please Fix auto-resize in radiator view

Describe the bug
Hi, I think the auto-resize in radiator view is broken.
It already got fixed in 3.5, maybe the code was changed again?
Puppetboard version
4.1
Environment and installation method
Tested on Ubuntu 20.04 with Firefox (latest) and Chromium (latest)
Thank you for your awesome work ...
Kind Regards
Rene

Hi @REHICode! Thanks for reporting and for your kind words. 😊
I am not sure what the issue is though. The radiator looks like this on one of my instances:

What are you seeing? Can you share a screenshot too please?
Of course if you know how to fix this then a PR with a fix is very welcome too. :)

Hi @gdubicki , it basically looks the same.
But if you resize your browser window, the radiator view should resize as well.
That is not the case anymore ;)

Strange - it resizes for me.
Are you using the offline mode perhaps?

Okay, that is really strange. If it resizes on your machine, then I'll have to test some things on my end.
I am on vacation for 2weeks now so not able to do the testing.
I will close this issue and hopefully will not have to ask you to open it again ;-)
Thank you

@gdubicki, finally I had the time to investigate the issue.
Just for documentation reasons ...
Yes we are using offline mode.
In /srv/puppetboard/virtenv-puppetboard/lib64/python3.8/site-packages/puppetboard/templates/radiator.html the jquery.min.js for offline mode could not be found.
I had to replace:
    <script src="{{ url_for('static', filename='jquery-3.6.0/jquery.min.js') }}"></script>
with
    <script src="{{ url_for('static', filename='libs/jquery/jquery.min.js') }}"></script>

Nice catch! Can you make a PR to fix it, @REHICode?

Thanks, sure thing - see: https://github.com/voxpupuli/puppetboard/pull/763

Thanks, merged and released in v4.2.6 today.


Loudness analysing gives strangely large/small results

After upgrading to newest beta problem doesn't occurs so often, but it still does. Im working with huge amount of short files (<1sec) maybe that matters?
Before upgrading to beta I had like 20 simillar results for 200 files, now i get 1-3.

Hi,
could you upload one of the files that gives such problem?
(If it's problematic to link publicly you can also PM me on the Reaper forum:
https://forum.cockos.com/member.php?u=6870)
With a specific problematic file, is the result erratic (varies with consecutive measurements) or reproduceable?
Do you have any take/track volume automation going on?

Hi,
Thank you for your fast reply and for your work on SWS, it is invaluable.
It seems to be not file related, because  now, 3 days later  measuring same file gives normal results. Unfortunately  as in spite i cannot reproduce the error which is strange, because I get it quite often in past 1 or 2 years. As fast I'll get it I'll send you the file. And the result is erratic (sometimes after few measurements it shows true value, and another files show "bad/strange" value).


This change checks for 403 errors, and if they exist, stops retrying and throws an exception

Would be great to have some unit tests for this code.
I know that there are no tests for http module whatsoever but maybe this is the point where we should start writing them.
Otherwise it is hard to tell whether this change should work.

Unit tests would be good.
In this case, I tested by running it through:

with a config file with working credentials - ran (as desired)
with a config file with non-working credentials - failed by raising the
ConnectionError (as desired)

On Mon, Oct 5, 2015 at 9:28 AM, Jakub Sendor<EMAIL_ADDRESS>wrote:

Would be great to have some unit tests for this code.
I know that there are no tests for http module whatsoever but maybe this
is the point where we should start writing them.
Otherwise it is hard to tell whether this change should work.
—
Reply to this email directly or view it on GitHub
https://github.com/Yelp/threat_intel/pull/47#issuecomment-145591238.

Where are the files for unit test? I don't see anything inside /tests...


Allow people to join teams from the inbox page

It should be possible to join the team from the inbox page without having to look up the team.
If that is problematic to implement the message should at least contain a link to the teams page.

This issue is fixed in 662f2418ed3c9ef04cbf42d34e0053d624031cca


ServiceDiscovery doesn't advertise ServiceProfile's port

Not sure who to tag, since there's no activity on this repository but @jdomnitz doesn't have issues enabled on theirs.
Basically, I'm using a random port for the server so there's not a well-defined port to agree on beforehand, but this information is available in the ServiceProfile and there is a SRV record in the AdditionalRecords.
Other mdns responders  (in particular, Oculus' AirLink is particularly chatty about advertising itself) do seem to include a port with their SRVRecords; presumably, there is no issue in the query, just the response.

I was mistaken and the port as provided to the ServiceProfile in my code was getting incorrectly set.

Thanks for the heads up.  Issues enabled now for the next bug.


docs: add the portuguese documentation

I am just adding the Portuguese documentation.
I already done vuejs-translations/docs-pt and vitejs/docs-pt, so I was thinking to expand the efforts 😊.
@lmiller1990

Should this be merged into the main repo? How does the core docs manage it?
Appreciate the effort! Have some concerns about maintenance moving forward, how is this currently managed in other translation repos?

@lmiller1990 I think it should be available to everyone like others and about the maintenance I consider myself an accountable person and I intend to improve and maintain the documentation as I do with the vuejs-translations/docs-pt and vitejs/docs-pt.

Ok, let's do it. Thanks!


Return stack frames of crashed thread when using wasm-c-api

When using the wasm-c-api and there's a trap, wasm_func_call() returns a wasm_trap_t * object.
No matter which thread crashes, the trap contains the stack frames of the main thread.
With this PR, when there's an exception, the stack frames of the thread where the exception occurs are stored into the thread cluster. wasm_func_call() can then return those stack frames.

@wenyongh Not sure I understand what CI is complaining about
CP libvmlib.a  <=  /home/runner/work/wasm-micro-runtime/wasm-micro-runtime/product-mini/platforms/linux-sgx/enclave-sample/../build/libvmlib.a
/usr/bin/ld: libvmlib.a(thread_manager.c.o): in function `wasm_cluster_set_exception':
thread_manager.c:(.text.wasm_cluster_set_exception+0x2a): undefined reference to `wasm_interp_create_call_stack'
/usr/bin/ld: thread_manager.c:(.text.wasm_cluster_set_exception+0x175): undefined reference to `wasm_interp_dump_call_stack'

I'm already guarding those 2 function calls with #if WASM_ENABLE_DUMP_CALL_STACK != 0.

@wenyongh Not sure I understand what CI is complaining about
CP libvmlib.a  <=  /home/runner/work/wasm-micro-runtime/wasm-micro-runtime/product-mini/platforms/linux-sgx/enclave-sample/../build/libvmlib.a
/usr/bin/ld: libvmlib.a(thread_manager.c.o): in function `wasm_cluster_set_exception':
thread_manager.c:(.text.wasm_cluster_set_exception+0x2a): undefined reference to `wasm_interp_create_call_stack'
/usr/bin/ld: thread_manager.c:(.text.wasm_cluster_set_exception+0x175): undefined reference to `wasm_interp_dump_call_stack'

I'm already guarding those 2 function calls with #if WASM_ENABLE_DUMP_CALL_STACK != 0.

There are interpreter mode and aot mode, for the latter, we should use aot_create_call_stack, and if aot mode is compiled and interpreter isn't compiled, the above error may be reported.

@wenyongh In my last commit I pushed a change to make it work with the thread manager both enabled and disabled. I don't understand why that commit is required since in both cases a Vector * is used, but a different cast is necessary to access the elements properly.
As a side note, I was testing my changes with:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <inttypes.h>

#include "wasm_c_api.h"

#define own

void print_frame(wasm_frame_t* frame) {
  printf("> %p @ 0x%zx = %"PRIu32".0x%zx\n",
    wasm_frame_instance(frame),
    wasm_frame_module_offset(frame),
    wasm_frame_func_index(frame),
    wasm_frame_func_offset(frame)
  );
}

int main(int argc, const char* argv[]) {
  // Initialize.
  printf("Initializing...\n");
  wasm_engine_t* engine = wasm_engine_new();
  wasm_store_t* store = wasm_store_new(engine);

  // Load binary.
  printf("Loading binary...\n");
#if WASM_ENABLE_AOT != 0 && WASM_ENABLE_INTERP == 0
  FILE* file = fopen("trap.aot", "rb");
#else
  FILE* file = fopen("trap-threads.wasm", "rb");
#endif
  if (!file) {
    printf("> Error loading module!\n");
    return 1;
  }

  int ret = fseek(file, 0L, SEEK_END);
  if (ret == -1) {
    printf("> Error loading module!\n");
    fclose(file);
    return 1;
  }

  long file_size = ftell(file);
  if (file_size == -1) {
    printf("> Error loading module!\n");
    fclose(file);
    return 1;
  }

  ret = fseek(file, 0L, SEEK_SET);
  if (ret == -1) {
    printf("> Error loading module!\n");
    fclose(file);
    return 1;
  }

  wasm_byte_vec_t binary;
  wasm_byte_vec_new_uninitialized(&binary, file_size);
  if (fread(binary.data, file_size, 1, file) != 1) {
    printf("> Error loading module!\n");
    fclose(file);
    return 1;
  }
  fclose(file);

  // Compile.
  printf("Compiling module...\n");
  own wasm_module_t* module = wasm_module_new(store, &binary);
  if (!module) {
    printf("> Error compiling module!\n");
    return 1;
  }

  wasm_byte_vec_delete(&binary);

  // Instantiate.
  printf("Instantiating module...\n");
  wasm_extern_vec_t imports = WASM_EMPTY_VEC;
  own wasm_instance_t* instance =
    wasm_instance_new(store, module, &imports, NULL);
  if (!instance) {
    printf("> Error instantiating module!\n");
    return 1;
  }

  // Extract export.
  printf("Extracting exports...\n");
  own wasm_extern_vec_t exports;
  wasm_instance_exports(instance, &exports);
  if (exports.size < 2) {
    printf("> Error accessing exports!\n");
    return 1;
  }

  wasm_module_delete(module);
  wasm_instance_delete(instance);

  // Call.
  int _start_function_index = 1;
  const wasm_func_t* func = wasm_extern_as_func(exports.data[_start_function_index]);
  if (func == NULL) {
    printf("> Error accessing export!\n");
    return 1;
  }

  printf("Calling export %d...\n", _start_function_index);
  wasm_val_vec_t args = WASM_EMPTY_VEC;
  wasm_val_vec_t results = WASM_EMPTY_VEC;
  own wasm_trap_t* trap = wasm_func_call(func, &args, &results);
  if (!trap) {
    printf("> Error calling function, expected trap!\n");
    return 1;
  }

  printf("Printing message...\n");
  own wasm_name_t message;
  wasm_trap_message(trap, &message);
  printf("> %s\n", message.data);
  assert(message.num_elems > 0);
  assert(strncmp(message.data, "Exception: ", strlen("Exception: ")) == 0);

  printf("Printing origin...\n");
  own wasm_frame_t* frame = wasm_trap_origin(trap);
  if (frame) {
    print_frame(frame);
    wasm_frame_delete(frame);
  } else {
    printf("> Empty origin.\n");
  }

  printf("Printing trace...\n");
  own wasm_frame_vec_t trace;
  wasm_trap_trace(trap, &trace);
  if (trace.size > 0) {
    for (size_t i = 0; i < trace.size; ++i) {
      print_frame(trace.data[i]);
    }
  } else {
    printf("> Empty trace.\n");
  }

  wasm_frame_vec_delete(&trace);
  wasm_trap_delete(trap);
  wasm_name_delete(&message);

  wasm_extern_vec_delete(&exports);

  // Shut down.
  printf("Shutting down...\n");
  wasm_store_delete(store);
  wasm_engine_delete(engine);

  // All done.
  printf("Done.\n");
  return 0;
}

(copied from samples/wasm-c-api/src/trap.c with small modifications, it requires setting WAMR_BUILD_LIB_WASI_THREADS)
trap-threads.wasm was generated from
fn c() { panic!("PANIC!!!"); }
fn b() { c(); }
fn a() { b(); }

fn main() {
    let handler = std::thread::spawn(|| {
        a();
    });
    handler.join().unwrap();
}

And it seems to work properly, i.e. it prints the stack trace of the spawned thread instead of the main thread.

When using the wasm-c-api and there's a trap, wasm_func_call() returns a wasm_trap_t * object. No matter which thread crashes, the trap contains the stack frames of the main thread.

do you mean, you are using wasm_func_call to call a "main" function, which internally creates "sub" threads?
in that case, to me, it seems reasonable to return the stack frames which includes the main function.

do you mean, you are using wasm_func_call to call a "main" function, which internally creates "sub" threads?

Yes

in that case, to me, it seems reasonable to return the stack frames which includes the main function.

But the stack trace of the main thread doesn't carry information about what caused the trap. If something crashed in the spawned thread we want to know what made it happen.
The alternative would be to return the stack frames of all threads, but I wanted to stick the wasm-c-api (that returns a single wasm_trap_t *). And I think that the stack trace of the crashed thread is probably enough in most scenarios (to troubleshoot the problem).
I'll resume the work once I'm back from vacation.

do you mean, you are using wasm_func_call to call a "main" function, which internally creates "sub" threads?

Yes

ok.

in that case, to me, it seems reasonable to return the stack frames which includes the main function.

But the stack trace of the main thread doesn't carry information about what caused the trap. If something crashed in the spawned thread we want to know what made it happen.

i can understand.
but as far as i understand, wasm-c-api doesn't have an api appropriate for the purpose.

The alternative would be to return the stack frames of all threads, but I wanted to stick the wasm-c-api (that returns a single wasm_trap_t *). And I think that the stack trace of the crashed thread is probably enough in most scenarios (to troubleshoot the problem).

i suspect you need to invent an extra api either ways.

I'll resume the work once I'm back from vacation.

enjoy your vacation!

i can understand.
but as far as i understand, wasm-c-api doesn't have an api appropriate for the purpose.

The current API already returns a wasm_trap_t * and I think it would be more appropriate to populate it with the stack frames of the crashed thread rather than the main thread.
Like when you're debugging with gdb and there's a crash, you get stopped on the crashed thread and running (gdb) backtrace returns the stack trace of that crashed thread.
Then yeah, it probably makes sense to have an additional API that would return the stack frames for all threads.

i can understand.
but as far as i understand, wasm-c-api doesn't have an api appropriate for the purpose.

The current API already returns a wasm_trap_t * and I think it would be more appropriate to populate it with the stack frames of the crashed thread rather than the main thread.

it might be appropriate for your use cases. it might not for others.
i personally feel it's less surprising to return the frames of the executed function.
after all, wasm-c-api in not a wamr-specific api. maybe you can make a proposal there if you want.

I agree with @yamt that before changing the behavior of the existing API, it's worth discussing it in a different forum. Having said that, IMO a new API that returns stack traces from all the functions would be quite useful for the debugging purposes, and I think it'll serve your purpose @eloparco - even though often having a stack of crashed thread is enough, sometimes it's necessary what was happening in other threads to narrow down the problem.

I agree with @yamt that before changing the behavior of the existing API, it's worth discussing it in a different forum. Having said that, IMO a new API that returns stack traces from all the functions would be quite useful for the debugging purposes, and I think it'll serve your purpose @eloparco - even though often having a stack of crashed thread is enough, sometimes it's necessary what was happening in other threads to narrow down the problem.

@loganek so should I merge the PR? It seems that all the issues were resolved and it looks good to me now.

Given the expectation from this API is not very well defined, I'm ok with the implementation proposed by @eloparco . However, this is a breaking change and must be highlighted in release notes. I don't know how many usecases will be affected though by that breaking change. I presume this is only for debugging / investigation purposes, so likely not many?

Given the expectation from this API is not very well defined, I'm ok with the implementation proposed by @eloparco . However, this is a breaking change and must be highlighted in release notes. I don't know how many usecases will be affected though by that breaking change. I presume this is only for debugging / investigation purposes, so likely not many?

Agree, I think there should be few cases affected, one is there should be few developers using wasm-c-api with multi-threading support, another is that dump-call-stack feature is usually disabled and is enabled mainly for debugging/investigation. For the latter, this PR helps to locate the actual issue. So I think it should acceptable, and yes, we can highlight the breaking change in the release notes. How do you think?

@loganek I merged the PR, and let's highlight it in release notes.

Sounds good, thanks

Thanks for merging, I wanted to point out that reporting only the stack trace of the crashed thread is also the default behaviour when running Wasmtime (tried with the latest dev branch). Running the same wasm file I was using with the wasm-c-api:
target/debug/wasmtime --dir . -W threads -S threads trap-threads.wasm
thread '<unnamed>' panicked at src/main.rs:2:5:
PANIC!!!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: error while executing at wasm backtrace:
    0: 0xcc2c - <unknown>!__rust_start_panic
    1: 0xc711 - <unknown>!rust_panic
    2: 0xc698 - <unknown>!std::panicking::rust_panic_with_hook::h6c1623ae744881b6
    3: 0xb625 - <unknown>!std::panicking::begin_panic_handler::{{closure}}::h8474ba3fc2a2f64f
    4: 0xb58a - <unknown>!std::sys_common::backtrace::__rust_end_short_backtrace::h2d8a3004b92235a1
    5: 0xbfeb - <unknown>!rust_begin_unwind
    6: 0x121f3 - <unknown>!core::panicking::panic_fmt::h4d6ec91b4ec3c102
    7: 0x6943 - <unknown>!hello_cargo::c::hde6caa0faf591098
    8: 0x694d - <unknown>!hello_cargo::b::hf5ff17be23138f3f
    9: 0x6957 - <unknown>!hello_cargo::a::hfef53f62412b3f11
   10: 0x3efc - <unknown>!hello_cargo::main::{{closure}}::h2356b4434e2f30cd
   11: 0x6e65 - <unknown>!std::sys_common::backtrace::__rust_begin_short_backtrace::hc386d72b956247a7
   12: 0x314d - <unknown>!std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}::h2008147d7c9f7289
   13: 0x74a0 - <unknown>!<core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h39f99754f0e7004a
   14:  0x668 - <unknown>!std::panicking::try::do_call::h3bec9c3b34ebe264
   15:  0x5b1 - <unknown>!std::panicking::try::ha20e4a80b1643c99
   16: 0x304c - <unknown>!std::thread::Builder::spawn_unchecked_::{{closure}}::h4e8c3a41a9981963
   17: 0x3f5f - <unknown>!core::ops::function::FnOnce::call_once{{vtable.shim}}::h2ffb3ae107c3a7de
   18: 0xcbbe - <unknown>!std::sys::wasi::thread::Thread::new::thread_start::h3c4c4269952012d9
   19: 0x10e77 - <unknown>!__wasi_thread_start_C
   20: 0x119c9 - <unknown>!wasi_thread_start
note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information

Caused by:
    wasm trap: wasm `unreachable` instruction executed

If I have some time in the future, I'll investigate how to report stack frames from all threads (I guess we would have to use a similar approach and modify the wasm_trap_t struct, plus adding some additional APIs).

If I have some time in the future, I'll investigate how to report stack frames from all threads (I guess we would have to use a similar approach and modify the wasm_trap_t struct, plus adding some additional APIs).

have you done so since then?
have you proposed this to wasm-c-api?
otherwise, i'd suggest to revert this because:

this is a non-standard behavior, surprising users.
it's reported broken: https://github.com/bytecodealliance/wasm-micro-runtime/discussions/3800#discussion-7202551


Pil Display always uses namespaced access even in the same namespace

If a name from the current namespace is referenced, the Display trait should not explicitly mention the namespace.
Example:
namespace Assembly(2);
    col fixed A = [0]*;
    col fixed C(i) { Assembly.A(i) };

This should print to
namespace Assembly(2);
    col fixed A = [0]*;
    col fixed C(i) { A(i) };

instead.

@chriseth unfortunately one of the pitfalls of the Display trait is that it does not allow for passing additional information or additional function arguments, so we will have to pick from one of a couple different design options---some choices better than others IMHO.
Do we think that this information (i.e. the referenced namespace is the current namespace) will be useful to know in the AST? In that case we could add an additional boolean field that denotes if the referenced namespace is the current namespace.
If we don't want to modify the AST, we could implement a custom display trait (okay), implementDisplay on (String, T) (okay-ish), could introduce a global singleton (bad), or some other approach.
What are your thoughts?


Feature add crud base

This PR facilitates the creation of the basic CRUD operations for new db_models objects.
One does not need to copy/paste app.crud.items.py into app.crud.your_model.py file anymore. One line is sufficient in app.crud.__init__.py (with appropriate import):
your_model = CrudBase(YourModel)

The PR therefore defines a CrudBase class, which instances will provide the get/get_multi/create/udpate/delete/remove operations for a given SQLAlchemy object. I have tried to be as detailed as possible in the documentation of app.crud.base.py
Along with this new tool, I have added a new SubItem model that showcases the usage of CrudBase. I have also modified Item with the same objective. Tests have been added or updated consequently.

because we should be DRY 🚀

Very interesting ideas! I'll check it thoroughly soon.

Just to chime in, I'm not a contributor but been using the contents of this PR in my project and it works fine and seems cleaner.

Sorry for all the comment @ebreton, they are because I liked an used the PR :)

no worries @wassname , its awesome to see you comment and improve :)
I am just deep underwater right now, but I appreciate 👍

A little bit tangential, but on the topic of crud, here's an approach I came across using sqlalchemy mixins.

A little bit tangential, but on the topic of crud, here's an approach I came across using sqlalchemy mixins.

I will need to dive a bit further into SQLAlchemy, I have not used their MixIns yet

I've been using sqlalchemy_mixins for a while now, and actually it made me make some substantial changes to the template. For example, it's not necessary to pass the database as a dependency injection anymore, because you can set the session on the base class. It's quite convenient I must say. I still use the crud object though because sometimes the operations necessary can be quite complex.

I don't suppose you could share an example, or a gist few anonymized files? It's always interesting to see implementation details of something we're working on.

@tiangolo , I have put a lot of things in this one, which goes along with the initial purpose: simplify the crud definitions, and make a clearer distinction between schemas and models.
Hope you will find it useful... 🤞

I like the models=>schemas, cleaning up the user crud. I've been using UserExpanded schemas to returns lists of items too. <3 pytest fixtures.
Thanks, I've made wanted to make similar changes to my project.

Hi @tiangolo !
I was wondering if I could something to help you accept this PR 😇

This PR looks amazing. Would be great if we could get merge.

@ebreton @tiangolo Just a thought on this Pull Request as someone who is learning. This PR has taken the example application away from the examples in the FastAPI  documentation. It would be good if the example application and the docs were somewhat similar so that people could see real world examples. Specifically I am talking about the CRUD changes and things like UserInDB which appears to be no longer in use. I do appreciate that the code is cleaner in it's current incantation (and I have learnt a thing ot two about generics - thanks) but for someone who is following the documentation and trying to work out how everything fits together it makes understanding more difficult.
I am not overly concerned from my own point of view because  just checked out the revision before the merge and that helped me understand a lot better. I just think the the old style of code was simpler to understand for someone coming at this for the first time.
Thanks for all the awesome work.

You are right: I have focused on documenting the PR, and I have failed at updating the doc.
I guess it will come, but any help from you would be more than welcomed 😇 .
Would you please make a try at a PR where you could share your experience ? I would say that it would make the learning process much simpler, even simplest than the previous one once you get the trick (and one can always stick to the first version if it remains an option in the doc too)


Null token input getting converted to string literal

Describe the Bug with repro steps
When you create an action with a null input token in the old designer directly, you see the right value - @null
When you create an action in the new designer is when you get @{null}
This difference also occurs on other keywords like true and false

https://portal.microsofticm.com/imp/v3/incidents/incident/424723241/summary
What type of Logic App Is this happening in?
Standard (Portal)
Are you using new designer or old designer
New Designer
AB#25431297

@rllyy97 I'm seeing the same interaction between old/new designer - both when the parameter value is a single valuesegment resulting in @, and when its a nested object (ex dynamic data) or parameter value with  multiple valuesegments, resulting in @{}


Provide a GH permissions template

See https://github.com/jenkins-infra/helpdesk/pull/3299
I removed the permissions level dropdown, given teams typically have admin permissions over the repository.

Looks fine, you might want to add a issue template config and change the number in the filename.


Broke out wordcount problem/solution into separate packages under single gradle subproject

Updated master with Matt's solution for the wordcount problem.

Added new subpackages for problem & solution to keep both under single gradle subproject

Closing this since issuing pull requests against a forked repo to pull updates in from its origin is probably not a best practice.


add os.read_file()

used readfile not read_file since you already have readlink

It's not a strict rule, but, I tried to respect Go equivalent function's Camelcase. For example. readlink was os.Readlink. So I think it should be read_file as it's matching ioutil.ReadFile.

It's not a strict rule, but, I tried to respect Go equivalent function's Camelcase. For example. readlink was os.Readlink. So I think it should be read_file as it's matching ioutil.ReadFile.

update

travis needs to be reran was an environmental failure


New Integration: Grünbeck softliQ

This issue is a request for a new integration.
General information

Manufacturer: Grünbeck
Modell: softliQ SC18
Type: Water softening
Product website: https://www.gruenbeck.de/en/products-industries/products/water-softeners/anti-scaling/softliqsc18/

API
Request
curl --data-binary "id=8151&show=D_A_1_1|D_A_1_2|D_A_1_3|D_C_2_1|D_A_2_1|D_A_2_2|D_A_3_1|D_A_3_2|D_C_5_1|D_Y_5|D_Y_6|D_Y_7|D_Y_10|D_Y_2_1|D_Y_2_2|D_Y_2_3|D_Y_2_4|D_Y_2_5|D_Y_2_6|D_Y_2_7|D_Y_2_8|D_Y_2_9|D_Y_2_10|D_Y_2_11|D_Y_2_12|D_Y_2_13|D_Y_2_14&code=0~" 'http://<IP_ADDRESS>/mux_http'

Response
<data>
    ok
    <D_A_1_1>0.00</D_A_1_1>
    <D_A_1_2>0.17</D_A_1_2>
    <D_A_1_3>6.2</D_A_1_3>
    <D_C_2_1>0</D_C_2_1>
    <D_A_2_1>0.0</D_A_2_1>
    <D_A_2_2>000</D_A_2_2>
    <D_A_3_1> 9</D_A_3_1>
    <D_A_3_2>82</D_A_3_2>
    <D_C_5_1>0</D_C_5_1>
    <D_Y_5>0</D_Y_5>
    <D_Y_6>V01.01.02</D_Y_6>
    <D_Y_7>-</D_Y_7>
    <D_Y_10> 68</D_Y_10>
    <D_Y_2_1>165</D_Y_2_1>
    <D_Y_2_2>273</D_Y_2_2>
    <D_Y_2_3>137</D_Y_2_3>
    <D_Y_2_4>110</D_Y_2_4>
    <D_Y_2_5>271</D_Y_2_5>
    <D_Y_2_6>85</D_Y_2_6>
    <D_Y_2_7>145</D_Y_2_7>
    <D_Y_2_8>130</D_Y_2_8>
    <D_Y_2_9>256</D_Y_2_9>
    <D_Y_2_10>261</D_Y_2_10>
    <D_Y_2_11>126</D_Y_2_11>
    <D_Y_2_12>116</D_Y_2_12>
    <D_Y_2_13>121</D_Y_2_13>
    <D_Y_2_14>112</D_Y_2_14>
</data>

Context
Above is the API call for this iPhone App view (numbers might differ):

API Documentation
While browsing, I found a Homematic forum entry (see Script für SC18 Grünbeck Enthärtungsanlage (language is german). This post had documentation attached. It describes all parameters for read- and write access: Webserver_Dokumentation.pdf
Implementation
At first, I would suggest a read-only implementation.

Parameter
Type
Example

ip
string
<IP_ADDRESS>

Community work
There seems to be an alternative implementation by using the platform: command_line.
See Gruenbeck Soft Water sensor Durchfluss @ Home Assistant Community Forum.
Integrations of other systems

ioBroker
openHAB

What this issue is about
This issue is not an "I want this, please do this"-thing.
I open this issue for three main reasons

To check back with you (the project owners/the community) if a native Home Assistant Integration is welcomed (before putting the work in)
To write down all details of the integration and discuss a potential design/implementation with you (e.g. to get the best solution, answer open questions)
To mark who is doing the implementation and save time in case of double work. I am not expecting that you (the project owners/the community) are doing the integration and i am the person who benefits. I might be do the implementation myself and contribute back. Maybe someone is faster, has a local branch ready somewhere or is just keen to learn how to do it.

Especially 1. and 2. might decrease the time inside a Pull Request because details are often clarified already.
Open questions

Is a native integration welcomed? Or is the platform: command_line-way (described in the community forum) the solution?
Can someone from the community confirm the API? (e.g. if you own such a system at home)
Do you have any open questions?

In general, *please let me know what you think about this.

Thank you for reaching out. We use GitHub for tracking issues, not for providing support or tracking feature requests. Therefore, please close this issue.
If you want to suggest a feature, you should try our Community Forum: Feature Requests.
If you have additional questions, feel free to join our Discord chat server.
Thanks! 👍

Thanks @springstan for the quick answer.
I understand. I raised this, because in your https://github.com/home-assistant/home-assistant/blob/dev/CONTRIBUTING.md, you link to https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#best-practices-for-faster-reviews, which states 1. Is the feature wanted? File a Kubernetes Enhancement Proposal.
I raised this ticket to check if the feature is wanted.
To avoid future confusion by newcomers, do you think it would be a good idea to write a guideline to a more prominent space? E.g. in the https://github.com/home-assistant/home-assistant/blob/dev/CONTRIBUTING.md?
Or maybe remove the link to Kubernetes and copy/paste it over + adjust it?
And what is the right place to discuss/document design decisions? Would it also be the community forum?

I raised this ticket to check if the feature is wanted.

I completely understand where you are coming from, however my impression is that more people are active in the community forum so it is a good idea to discuss feature requests there.

To avoid future confusion by newcomers, do you think it would be a good idea to write a guideline to a more prominent space? E.g. in the https://github.com/home-assistant/home-assistant/blob/dev/CONTRIBUTING.md?
Or maybe remove the link to Kubernetes and copy/paste it over + adjust it?

That sounds like a good idea, feel free to open a PR for that.

And what is the right place to discuss/document design decisions? Would it also be the community forum?

Yeah the community forum is always a good idea and the Discord chat server as well.

Got it. Thanks @springstan
For the records: Here is the community entry -> https://community.home-assistant.io/t/new-integration-grunbeck-softliq/157478


Codewars doesn't use common or GF markdown concerning hard line breaks

Usually, only a newline creates a new paragraph, and you need spaces to create hard line breaks.
However, Codewars doesn't follow this style, which makes it sometimes awkward to write a description paragraph, since all text needs to stay in a single line.
Is this intended?

Apparently, GitHub uses different Markdown conventions. On markdown files, it won't  introduce a break since newlines are meant to keep lines reasonably short. In comments GitHub follows a more WYSIWYG related approach and transforms newlines into line breaks.


bypass some temporary ControlFlowGraph objects

I noticed that converting Bytecode back to executable code has a habit of creating temporary ControlFlowGraphs for the sole purpose of computing stacksize.  My own pet uses of this module have been to build a ControlFlowGraph, it seems wasteful to have one of those objects, then have a temporary one created all over again just to compute the stacksize.
Similarly, PeepholeOptimizer.optimize constructs a ControlFlowGraph from the passed Bytecode.  So also wasteful if you already have a ControlFlowGraph.
So in a nutshell.. this make PeepholeOptimizer.optimize_cfg() a public method.  This used to just be the private "_optimize()".  It's a simple change.
Then the to_code() methods on the different classes allow a stacksize to be passed in, with the intent being that if you have a CFG and can compute the stacksize that you're better off just using that.  It also allows you to specify a different stacksize if you think you know better: maybe you want to blow up CPython's stack (stacksize=big_number) or overflow the stack (stacksize=0) although I haven't tested those.

Codecov Report

Merging #30 into master will decrease coverage by 0.08%.
The diff coverage is 89.18%.

@@            Coverage Diff            @@
##           master     #30      +/-   ##
=========================================
- Coverage   93.48%   93.4%   -0.09%
=========================================
  Files          17      17
  Lines        2564    2592      +28
=========================================
+ Hits         2397    2421      +24
- Misses        167     171       +4

Impacted Files
Coverage Δ

bytecode/tests/test_bytecode.py
98.11% <100%> (+0.33%)
:arrow_up:

bytecode/peephole_opt.py
94.4% <100%> (ø)
:arrow_up:

bytecode/bytecode.py
89.62% <100%> (+0.09%)
:arrow_up:

bytecode/tests/test_cfg.py
99.62% <100%> (ø)
:arrow_up:

bytecode/concrete.py
94.81% <100%> (+0.01%)
:arrow_up:

bytecode/tests/test_concrete.py
99.73% <100%> (ø)
:arrow_up:

bytecode/tests/test_peephole_opt.py
96.07% <100%> (ø)
:arrow_up:

bytecode/cfg.py
94.82% <20%> (-1.65%)
:arrow_down:

Continue to review full report at Codecov.

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


[GHSA-8h22-8cf7-hq6g] Rails has possible Sensitive Session Information Leak in Active Storage

Updates

Affected products

Comments
The original advisory specifies that the vulnerability was in the activestorage gem, not the rails meta-gem.

Hi there @tenderlove and @jhawthorn! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.
This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory


Use jobs infrastructure for schema changes

Background: https://airtable.com/tblD3oZPLJgGhCmch/viw5Jsp2TrY3it9Yr/recoIfwx7vj4qsshU
PM: @awoods187
Eng: @vivekmenezes

@vivekmenezes I have looked at the code to try to determine which schema change statements run as jobs, and came up with the following list (checked = runs as a job).  Can you confirm if this is correct?

[ ] ALTER DATABASE
[X] ALTER INDEX
[ ] ALTER RANGE
[ ] ALTER SEQUENCE
[X] ALTER TABLE
[ ] ALTER VIEW
[ ] CREATE DATABASE
[X] CREATE INDEX
[ ] CREATE SEQUENCE
[ ] CREATE TABLE
[ ] CREATE VIEW
[X] DROP DATABASE
[X] DROP INDEX
[ ] DROP SEQUENCE
[X] DROP TABLE
[ ] DROP VIEW
[X] TRUNCATE

It seems like the docs work here will be (roughly):

Update docs for some statements to say they run as jobs, can be managed using the jobs infrastructure (SHOW JOBS, etc.)
Noting if there are any special cases in the above (e.g., "don't pause and resume an ALTER INDEX job under conditions ABC because XYZ will happen")
??? (other things I can't think of)

These should all be jobs--I'll file an issue https://github.com/cockroachdb/cockroach/issues/35514
Awesome work @rmloveland

Thanks Andy!  In light of our discussion, I'll move this issue to the 19.2 milestone since I can't really work on it yet.  (As always, shout if you disagree.)

@rmloveland, seems like we've updated the docs as far as possible for 19.1, is that right? If so, would you mind closing this and opening a follow-up issue for the remaining work. In principle, that remaining work should be on the 19.2 roadmap anyway, if it's prioritized.

@rmloveland, seems like we've updated the docs as far as possible for 19.1, is that right?

Not yet - I prematurely bumped this issue to 19.2.
The remaining work is to ensure the statements listed above with checkmarks are tagged as visible using SHOW JOBS.
I'll do that and PR it ASAP, then make the follow-up issue for 19.2.


Cyrilic file names

When uploading file with cyrilic name
upload file without name

when add: setlocale(LC_ALL, 'ru_RU.UTF-8');
change all names to "___"
comment line 128 in  /src/controllers/UploadController.php
// $new_filename = preg_replace('/[^A-Za-z0-9-']/', '_', $new_filename);
working good

You can simply set 'alphanumeric_filename' to false in lfm.php.


View and query resource metrics in Log Analytics

As a project developer, I want a set of basic KQL queries that utilize Log Analytics tables saved to the repository, so that the team can begin familiarizing with querying Log Analytics using KQL

[ ] Documentation added that outlines where to retrieve resource logs and metrics
[ ] At least 1 metric's retrieval process documented[ ] At least 3 KQL queries that use resource-specific Log Analytics Workspace tables documented (https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/tables-resourcetype)

Mentioned in #333


Simplify end user experience with single "import Kitura"

A user's first experience using Kitura should be VERY simple, and require only a modest level of knowledge to stand up a server.
Currently, a user needs to include 3 or more imports to utilize Kitura. This feels overly complex, and "exposing how the sausage is made".  The main import Kitura should be an aggregate class that includes all the core classes, that would cover the basic use cases.
Concerns:

Whats the build time penalty?
Whats the output binary size increase?
Would there be any class conflicts, and how to mitigate?
Would still need to enable discreet imports of targeted sub-classes for fine grained control
Rename current Kitura class to KituraCore or similar.

This reminds me of this issue: https://github.com/IBM-Swift/Kitura/issues/30. I agree with this idea. If there is a way to do this, we should make it a priority.

@dfirsht there is actually a way to use only import Kitura by adding @_exported attribute to any import statement in any source file so it would look like this:
@_exported import KituraNet
@_exported import KituraSys

I think once refactoring for #467 is done, we might not need to import KituraNet and KituraSys.

We think that much of KituraSys will go away and what's left is probably not needed by the average developer.
That makes this two imports instead of three.
We are at this unsue of using the undocument @_exported annotation as supposedly it causes issues with XCoe (according to Apple)


Don't warn about w0201 in improper places

Description
Don't warn about w0201 in improper places
Type of change

[x] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)
[ ] CI configuration change
[ ] Konflux configuration change

/retest

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

Project coverage is 94.90%. Comparing base (78bd028) to head (3b87c70).
Report is 24 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1709   +/-   ##
=======================================
  Coverage   94.89%   94.90%
=======================================
  Files          60       60
  Lines        2685     2689    +4
=======================================
+ Hits         2548     2552    +4
  Misses        137      137

Files with missing lines
Coverage Δ

ols/src/cache/in_memory_cache.py
97.77% <ø> (ø)

ols/src/cache/redis_cache.py
100.00% <ø> (ø)

ols/src/rag_index/index_loader.py
92.72% <ø> (ø)

/approve

/override "Red Hat Konflux / ols-enterprise-contract / lightspeed-service"

/lgtm

/override "ci/prow/e2e-ols-cluster-4-16"


tab is duplicated when using ng-if and binded value for condition is refreshed

I have a tab with ng-if condition
<tab id="..." heading="..." ng-if='orphanInstances' >

And a function in the controller
$scope.refresh = function () {
...
     $scope.orphanInstances = data;
...

If I replace ng-if='orphanInstances' by ng-hide='!orphanInstances' I have only one tab, as expected.
AngularJS v1.2.0

I can confirm what nathantech2005 reported. I am still observing this issue right now in AngularJS 1.5.11.
It hinges on whether I put the ng-if in the same <div> as a custom directive of mine. If I do it like that, the <div> gets duplicated each time the the value of the ng-if condition has changed to a truth-y value. If I put the ng-if into an extra <div> that encloses the <div> with my custom directive instead, everything works fine.