added functionality to track overlapping accesses

This pull request address the issue of overlapping accesses for DSA as discussed by issue #254
Remaining:

[x]  create a test for global overlapping (can use clang/jumptable)
[x] create a test for stack overlapping
[x] test indirect overlapping access

I don't think this is working correctly yet.
For indirect_calls/jumptable/clang:BAP, these are the relevant instructions with overlapping stack accesses:
00000413: mem := mem with [R31 + 0x10, el]:u128 <- V0

00000429: R8 := mem[R31 + 0x10, el]:u64

00000438: R8 := mem[R31 + 0x18, el]:u64

The 128 bit access to R31 + 16 overlaps with the 64 bit access to R31 + 16 and the 64 bit access to R31 + 24.
However, the analysis doesn't correctly determine that these overlap. The results it gives are that:

00000429_R8 points to node 438 which contains pointers to add_six and add_two and is collapsed.
00000438_R8 points to node 447 which is empty.

There is also node 450 which contains Stack_16 (of size 16) and Stack_12 (of size 4). It has three cells:

0 points to node 438
8 points to node 447
12 points to node 439 (which is also empty).

This is incorrect - accesses to R31 + 16 and R31 + 12 never overlap, and these offsets don't make any sense.
Stack_12 and Stack_16 do not overlap and the analysis should not find that they do.
00000429_R8 should contain a pointer to add_two (this is already fine)
00000438_R8 should contain a pointer to add_six (this is not correct as-is)
It's alright if they both point to a collapsed node containing pointers both add_two and add_six, but it's even better if we can maintain the offsets if possible?

right now it checks if the DSA checks if the index is stack or global but instead it needs to check if a pointee is stack or global and merge them accordingly

The safest option is to grow the cell sizes of the cell which is being accessed to the access size. This however, will cause consecutive cells being collapsed together in the index.

// 0x10DC0 contains a pointer to the procedure add_two at the beginning is represented by a separate Node with a single cell which points to procedure add_two
// 0x10DC8 contains a pointer to the procedure add_six at the beginning is represented by a separate Node with a single cell which points to procedure add_six
when the analysis processes V0 := mem[0x10DC0, el]:u128

This seems to be working now so I'll merge it soon.
It would be nice to be able to improve the precision so it can tell that add_two is at offset 0 and add_six is at offset 8 in the combined node and then tell that 00000429_R8 is pointing to add_two, 00000438_R8 is pointing to add_six, and 0000040b_V0 is pointing to both, but that would probably be a fair bit more complex and isn't a must have.

Oh you were planning to write tests weren't you? I'll wait for you do to those before merging.

// 0x10DC0 contains a pointer to the procedure add_two: separate node with a single cell at the start which points to add_two
// 0x10DC8 contains a pointer to the procedure add_six: separate node with a single cell at the start which points to add_six

// 0x10DC0 contains a pointer to the procedure add_two: separate node with a single cell at the start which points to add_two
// 0x10DC8 contains a pointer to the procedure add_six: separate node with a single cell at the start which points to add_six
once the analysis process
V0 := mem[0x10DC0, el]:u128
it will merge the nodes for 0x10DC0 and 0x10DC8 with offset 8 so that the resulting node will have a cell at offset 0 which corresponds to 0x10DC0 and a cell at offset 8 corresponding to 0x10DC8. Each cell still has a distinct pointee
here currently the analysis will grow the cell corresponding to 0x10DC0 the size of the access. it causes that cell to overlap the cell corresponding to 0x10DC8 and as a result their outgoing edges (their pointees) are also merged. This causes the collapse
an alternative would be to not grow 0x10DC0's cell but instead do a multi load/write.
instead of growing the  0x10DC0's cell, we start from that cell and continue to merge each consecutive cell's pointee with a cell at a different offset in V0's Node. The problem here is that we don't have a way of telling which offsets are the correct ones in V0's node to be merged with the pointees. I think one possibility would be to increment a set number (64 bits or one pointer's length) since we are only concerned with pointers. However, I'm unsure of the full implications of this for soundness

It's tricky because I don't know what the best way would be to have it so that the V0 can be shown to contain both, but the R8s each point to a separate part. Probably too tricky to worry about any more for now, what we have now is good enough

here currently the analysis will grow the cell corresponding to 0x10DC0 the size of the access. it causes that cell to overlap the cell corresponding to 0x10DC8 and as a result their outgoing edges (their pointees) are also merged. This causes the collapse

I guess instead of this it would actually work if you just didn't collapse the node and just had 0000040b_V0 point to the base of the node, because we know V0 is 128 bits so it can be interpreted as being the whole node.

instead of growing the 0x10DC0's cell, we start from that cell and continue to merge each consecutive cell's pointee with a cell at a different offset in V0's Node. The problem here is that we don't have a way of telling which offsets are the correct ones in V0's node to be merged with the pointees.

Can you explain this further? I don't quite follow what the problem is, why don't we have a way of telling which offsets to use?

after V0 := mem[0x10DC0, el]:u128
we want V0 node to look something like
V0 = {Cell1 == pointee(0x10DC0), cell2 == pointee(0x10DC8)},
I don't we have a way of determining what offset cell2 begins at because we don't know the size of the pointee(0x10DC0)

We do actually know the sizes. The way it works is that:

add_two has address 0x754
add_six has address 0x768
0x10DC0 is a location that contains 0x754, so it is a pointer to a pointer to add_two
0x10DC8 is a location that contains 0x768, so it is a pointer to a pointer to add_six
These are all pointers which are 64-bit/8-byte values

Because 0x10DC8 is 8 bytes after 0x10DC0 and they are loaded together, we know that the offset for cell 2 is 8 just from that.

we would know the size if the pointee is a single (not merged with anything else) global object (possibly single stack objects aswell), because we can look it up in the symbol table and know its size and also know the object isn't merged with something else so we can rely on our known size. But I don't think we can tell the size in general. if pointee is not global or stack we won't be able to tell it's size, same thing follows if a stack or global object has been merged with some other nontrivial (not a place holder for SSA variables) object. But you are right we are able to get more precision in certain cases

We know the size because there is an object at 0x10DC0 and an object at 0x10DC8, and we are accessing both via a 128-bit access to 0x10DC0. This mean that 0x10DC8 is offset from 0x10DC0 by 8 bytes. This applies broadly, whether we are accessing global data, or the stack, or a heap location. We don't need to know anything about the symbol table for this (except that those objects exist at those addresses in this example).
Of course, if those objects have already been merged with anything else that has caused their nodes to collapse then you can't possibly do anything except collapse these together too, but that's fine.

You are so correct. OF COURSE we have sizes of the pointees because we use them to determine if there is an overlapping access. Thank you for clarifying that. My symbol table to global objects (Data Structure Nodes) conversion step is missing the middle indirection level (cell for 754 pointing to add_two) from 0x10DC0 to 754 to add_two. I'll fix that next and then should be able to get more precise overlapping accesses implemented.

Thanks, that makes sense. I agree that we need to add that extra indirection layer that isn't in there at present.

You accidentally overwrote some of your previous fixes with this force push

I'm not sure if this extra indirection actually makes sense either - I think I'd gotten a bit confused when I agreed that it was needed, so my apologies for that. The issue is that 0x754 is the address of the function add_two, so the value 0x754 is a function pointer to add_two. This means that any register that contains the value 0x754 is just pointing to add_two - it isn't pointing to a pointer to add_two. That would only be the case if a register held the value 0x10DC0 (which is an address that contains the value (0x754).
The difficulty we're dealing with is that we want to be able to have a node where cell 0 is add_two, and cell 8 is add_six, but I don't think that's really supported at the moment - would it be possible to implement something like that and does it make any sense as an approach?
Using negative addresses doesn't really seem like a sensible way to represent this either, if we wanted indirection like that a better option would probably be a new sort of node to represent functions, rather than negative addresses which would only be confusing as they don't actually mean anything.

I agree that the indirection doesn't seem correct specially because the global address range for the functions are shrunk but I think it makes sense to represent 0x754 as a cell pointing to add_two rather than add_two. This way we want a node where cell 0 is a pointing to add_two and cell 8 is a pointing to add_six which seems more correct than having add_two with size 20 bytes at cell 0 and add_six with size 20 bytes at cell 8.
we need a better way of representing function pointers. I think it is suitable to represent them as single cell nodes with the single cell pointing to the function (e.g. add_two). However, I think here the appropriate address range is [0x754, 0x754] but we want the cell to be 8 bytes long
I also agree with the negative address not being very sensible, currently all the globals have an address range but the current approach represents 0x754 to 0x754 + 8 as a pointer to add_two and hence had to put add_two itself in some range that won't be addressed.  I'm still unclear on how I want to represent the function pointers tho, so I think this should be addressed after the above issue is resolved

It depends on the semantics - varToCell maps each SSA Register to a Slice (a Cell and an offset into that Cell)  - does the Cell represent the value of the register, or what the register points to?

The cell represents the value. The cell may or may not be pointing to something

Ah, ok, the indirection is needed then, that clears things up. At the moment it feels like it's the other way around - a DataLocation with start 0x754 seems like it is representing the memory location 0x754, not the value 0x754 (which points to said memory location), so more work may need to be done to make this clear & consistent.
I think the simplest solution is that the cell with value 0x754 (which should have size 8 then) should then point to a cell containing a new type of MemoryLocation that represents a function?

Similar work may need to be done with DataLocations that represent the addresses of global variables too - there may need to be a new MemoryLocation that represents a global variable's contents (the value that is actually at the address)?

However, I think here the appropriate address range is [0x754, 0x754] but we want the cell to be 8 bytes long

The value 0x754 is a function pointer and is 8 bytes long, so the cell should be 8 bytes long if it represents that as a value. What does the address range actually mean? If cells represent values, then I'm not sure the concept of an address range is needed at all?

This pull request also seems to incorrectly identify overlapping accesses in some cases. An example of this is for correct/malloc_with_local/clang:BAP. There are no overlapping stack accesses in main(), but it incorrectly finds accesses to R31 + 4, R31 + 8 and R31 + 16 to be overlapping, even though the accesses to R31 + 4 are always 32-bit (so 4 bytes) and the other accesses are always 64-bit (so 8 bytes), meaning that there is no overlap
This is the .bir annotated with the accesses and allocations if it assists:
0000075d: sub main(main_argc, main_argv, main_result)
00000772: main_argc :: in u32 = low:32[R0]
00000773: main_argv :: in out u64 = R1
00000774: main_result :: out u32 = low:32[R0]

00000352:
00000356: R31 := R31 - 0x30
0000035c: #4 := R31 + 0x20
// access to R31 + 32
00000362: mem := mem with [#4, el]:u64 <- R29
// access to R31 + 40
00000368: mem := mem with [#4 + 8, el]:u64 <- R30
0000036e: R29 := R31 + 0x20
00000373: R8 := 0
// access to R31
0000037b: mem := mem with [R31, el]:u32 <- 31:0[R8]

// access to R31 + 28
00000382: mem := mem with [R29 - 4, el]:u32 <- 0
00000387: R0 := 1
0000038c: R30 := 0x834
// allocate heap1
0000038f: call @malloc with return %00000391

00000391:
// access to R31 + 16
00000397: mem := mem with [R31 + 0x10, el]:u64 <- R0
0000039c: R0 := 4
000003a1: R30 := 0x840
// allocate heap2
000003a3: call @malloc with return %000003a5

000003a5:
// access to R31 + 8
000003ab: mem := mem with [R31 + 8, el]:u64 <- R0
000003b0: R8 := 0xA
// access to R31 + 4
000003b8: mem := mem with [R31 + 4, el]:u32 <- 31:0[R8]
// access to R31 + 16
000003bf: R9 := mem[R31 + 0x10, el]:u64
000003c4: R8 := 0x41
// access to heap1
000003cc: mem := mem with [R9] <- 7:0[R8]
// access to R31 + 8
000003d3: R9 := mem[R31 + 8, el]:u64
000003d8: R8 := 0x2A
// access to heap2
000003e0: mem := mem with [R9, el]:u32 <- 31:0[R8]
// access to R31 + 16
000003e7: R8 := mem[R31 + 0x10, el]:u64
// access to heap1
000003ee: R1 := pad:64[mem[R8]]
000003f3: R0 := 0
000003f9: R0 := R0 + 0x8D4
000003fe: R30 := 0x878
00000401: call @printf with return %00000403

00000403:
// access to R31 + 8
00000408: R8 := mem[R31 + 8, el]:u64
// access to heap2
0000040f: R1 := pad:64[mem[R8, el]:u32]
00000414: R0 := 0
0000041a: R0 := R0 + 0x8E5
0000041f: R30 := 0x88C
00000421: call @printf with return %00000423

00000423:
// access to R31 + 4
00000428: R1 := pad:64[mem[R31 + 4, el]:u32]
0000042d: R0 := 0
00000433: R0 := R0 + 0x8F5
00000438: R30 := 0x89C
0000043a: call @printf with return %0000043c

0000043c:
// access to R31 + 16
00000441: R0 := mem[R31 + 0x10, el]:u64
00000446: R30 := 0x8A4
00000449: call @free with return %0000044b

0000044b:
// access to R31 + 8
00000450: R0 := mem[R31 + 8, el]:u64
00000455: R30 := 0x8AC
00000457: call @free with return %00000459

00000459:
// access to R31
0000045e: R0 := pad:64[mem[R31, el]:u32]
00000464: #5 := R31 + 0x20
// access to R31 + 32
00000469: R29 := mem[#5, el]:u64
// access to R31 + 40
0000046e: R30 := mem[#5 + 8, el]:u64
00000474: R31 := R31 + 0x30
00000479: call R30 with noreturn

The cells represent values but only values that matter are addresses. The values don't matter themselves, all we care about is  if the value is an address or not and where the address points to if it is. Therefore, I don't think we need to do this for non function globals.
Same with 0x754 the value doesn't matter as much as that it is represented by cell that points to add_two. I agree that the address range is not needed, however, it is convenient to be able to accesses globals with some unique key like their address for testing. And since the addresses are needed for fining appropriate offsets and overlapping accesses, we can represent the value 0x754 with address range 0x754 to 0x754  which is a cell that points to add_two like in the current iteration.

You do need to change how you represent other memory locations as well because otherwise it would be treating function pointers inconsistently with other pointers. For instance, currently the size of a DataLocation is the size of the object that the cell containing it points to, but since you are changing how you represent function pointers, then the size of a DataLocation will mean the size of the object pointed to for an object pointer, but the size of the pointer itself (or just 0 currently?) for a function pointer. 'DataLocation' is also a fairly unclear name given what it actually means - it should probably be something more like 'DataPointer'.
If you just want a unique key for testing, then there isn't a need for an address range at all - you could just use the value itself as a key? The value 0x754 isn't at the address 0x754, it's at the address 0x10DC0, so we need to make sure this is something that's handled consistently.

I just realized that the overlapping accesses only work the address being read/written to is directly a stack/global but not if there is a level of indirection. If there is any indirection same issue with inter procedural overlapping access occur. This issue is solved for interprocedural stack overlapping accesses and i'm currently working on the globals. Same solution can be applied to indirect overlapping accesses.
Effectively every merge (other than direct accesses to global/stack) has to be wrapped in extra functionality that checks for overlapping accesses to global/stack nodes through indirection. It's also possible to incorporate this into merge itself, but since we may require extra merges, have to find a suitable base case to end the recursion.
The current solution would be somewhat inefficient. To know if a node is a reference to a particular stack, or global. We have to run find() on all the stack/globals and see if they match. Through flags we can eliminate nodes that aren't stacks or globals.  Alternatively could implement a more accurate tracking of stack and globals through merges

I think we're going to want the more accurate tracking, even if that's more work to implement?

But if there's an easier, less efficient way, it's fine to implement that first I think?

Yeah I'm gonna try to fix it,  with the current inefficient way and open another and then implement tracking separately

This pull request also seems to incorrectly identify overlapping accesses in some cases. An example of this is for correct/malloc_with_local/clang:BAP. There are no overlapping stack accesses in main(), but it incorrectly finds accesses to R31 + 4, R31 + 8 and R31 + 16 to be overlapping, even though the accesses to R31 + 4 are always 32-bit (so 4 bytes) and the other accesses are always 64-bit (so 8 bytes), meaning that there is no overlap.

Is this still an issue, I'm not sure if it was fixed during the other updates or if I'm missing the problem but for me R31 + 4, R31 + 8 and R31 + 16 are separate nodes with a single cell and correct accessed sizes

I think you fixed that last week but I'll have another look to make sure now.

Yes, that's working now. The results generally seem to make sense now from what I can see, including in the jumptable/clang test.
This is the main thing that still needs to be addressed:

You do need to change how you represent other memory locations as well because otherwise it would be treating function pointers inconsistently with other pointers. For instance, currently the size of a DataLocation is the size of the object that the cell containing it points to, but since you are changing how you represent function pointers, then the size of a DataLocation will mean the size of the object pointed to for an object pointer, but the size of the pointer itself (or just 0 currently?) for a function pointer. 'DataLocation' is also a fairly unclear name given what it actually means - it should probably be something more like 'DataPointer'.
If you just want a unique key for testing, then there isn't a need for an address range at all - you could just use the value itself as a key? The value 0x754 isn't at the address 0x754, it's at the address 0x10DC0, so we need to make sure this is something that's handled consistently.

Currently a DataLocation can mean a location (which can even be a procedure) or a pointer to a location, and there isn't any consistency to what it means or what its size parameter means, which should be fixed. Right now the node with DataLocation(add_two's pointer, 1876, 0) (which represents a location containing the value 1876, which is a pointer to add_two) will point to the node with DataLocation(add_two, 1876, 20), which represents the actual procedure add_two with address 1876. This is inconsistent with the approach for global variables, where DataLocation(x, 69680, 4) represents a location containing the value 69680 (which is a pointer to x, not the actual location at address 69680), and points to another cell which represents the actual contents of x.

function pointers are handled similar to other globals now. The only difference is that the first cell will point to a special function Node instead of empty/placeholder node as its content.

I'm happy to merge this unless if you find other problems with it. I found an issue with the cloning of stack cells discussed in #274. I will address that in a general refactoring of how the stack handling works (remove SAA, track stack offsets via cells themselves, negative/overflow issues and cloning of stack cells)

I still think it would be good to change 'DataLocation' to 'DataPointer' as it represents a pointer, not a location.

function pointers are handled similar to other globals now. The only difference is that the first cell will point to a special function Node instead of empty/placeholder node as its content.

Thanks, this makes sense.
I'll merge this soon once I run some final checks. It's fine to leave the stack overhaul to another pull request.

I guess I'm still a bit confused by why the globalMappings table works like it does, why do we need to have a concept of an AddressRange when the globalMappings table is a mapping from AddressRanges to Fields, which are node + offset pairs that represent a cell containing the value that is the base of the address range? It's just a bit convoluted as-is. I feel like either it would make more sense for globalMappings to map to the cells representing the contents of the address range, or just have a mapping from addresses to the cell that contains that value?

I guess I'm still a bit confused by why the globalMappings table works like it does, why do we need to have a concept of an AddressRange when the globalMappings table is a mapping from AddressRanges to Fields, which are node + offset pairs that represent a cell containing the value that is the base of the address range? It's just a bit convoluted as-is. I feel like either it would make more sense for globalMappings to map to the cells representing the contents of the address range, or just have a mapping from addresses to the cell that contains that value?

The field is because we could have a global begin in the middle of a cell. We could instead have a cell/internal offset of the cell
The address ranges map to the base of the range. Having the end allows us to know whether an address in the middle of the range is point to the same memory location but an offset. We will not be able to determine this otherwise (for example from size of nodes/cells since those sizes are also affected by other merges) The address range in effect stores the size of the actual "global" which starts at the node + offset pair we are pointing to

The address range in effect stores the size of the actual "global" which starts at the node + offset pair we are pointing to
My point is that the node + offset pair refers to the cell containing the pointer to the memory location described by the address range. Why not just map directly to the cell representing the contents of the memory location described by the address range?

Like if we have a global variable x with address 69680 and size 4, then we will get the following entry in globalMappings:
AddressRange(69680, 69684) -> Field(Node(558, Data(x, 69680, 4)), 0)

Here, the cell at offset 0 in Node 558 is a cell that contains a pointer to the global variable x, not the contents of the global variable x, so why don't we just map directly from AddressRange(69680, 69684) to the cell that represents the contents of global variable x?

Here, the cell at offset 0 in Node 558 is a cell that contains a pointer to the global variable x, not the contents of the global variable x, so why don't we just map directly from AddressRange(69680, 69684) to the cell that represents the contents of global variable x?

This is true for the local graphs where the range always has a value at the beginning of the first cell  in the node but after a bunch of merges in the subsequent graphs the address range may start in the middle of a cell. So even if we have mapping like
AddressRange(69680, 69684) -> Cell(Node(558, Data(x, 69680, 4)), 0)
we will need to keep track of an internalOffset into the above cell to get
AddressRange(69680, 69684) -> Slice(Cell(Node(558, Data(x, 69680, 4)), 0), 1)
This is an alternative way we could track it but it's easier to track the offset directly instead of having to get the cell's offset and add it to it's internal offset to create "auxiliary" cells
So instead we have
AddressRange(69680, 69684) -> Field(Node(558, Data(x, 69680, 4)), 1)

So even if we have mapping like
AddressRange(69680, 69684) -> Cell(Node(558, Data(x, 69680, 4)), 0)
we will need to keep track of an internalOffset into the above cell to get
AddressRange(69680, 69684) -> Slice(Cell(Node(558, Data(x, 69680, 4)), 0), 1)

This isn't what I'm suggesting, and seem to be largely equivalent to what we already have. What I'm saying is that that Cell is one that contains a pointer to the global variable x - it doesn't represent the contents of global variable x. I'm wondering why we don't directly map from the AddressRange to the Cell (or Slice, or Field, whichever works) that represents the contents of the memory location represented by that AddressRange?

This isn't what I'm suggesting, and seem to be largely equivalent to what we already have. What I'm saying is that that Cell is one that contains a pointer to the global variable x - it doesn't represent the contents of global variable x. I'm wondering why we don't directly map from the AddressRange to the Cell (or Slice, or Field, whichever works) that represents the contents of the memory location represented by that AddressRange?

Sorry I misunderstood. I think we need a pointer to the location. That way if a global address is stored in the heap/stack or another global we can treat it like any other pointer. we could load a global pointer through indirection and not worry about it being a global (we kind of have to check because of overlapping accesses currently but we can treat them like any other dereference, otherwise we would have to merge the global location with its content but merge the pointees of any other access)

I think we need to revert this for the time being, the unsoundness issues are more significant than I thought.

I've reverted this, so make a new pull request for points_to_analysis_overlapping_access
I will outline the issues I've discovered in #276 now that I have time to do so.


find licenses for php

Problem to solve

support license_management for composer based projects

Further details
php projects normally use composer
Proposal
What does success look like, and how can we measure that?

extract license information from composer.lock file, contains all package licenses

    "packages": [
        {
            "name": "doctrine/annotations",
            ...
            "license": [
                "MIT"
            ],
            ...
        },
        ...

Links / references

https://gitlab.com/gitlab-org/gitlab-ee/issues/7739#note_110779175

@mainej can i somehow sponsor that ability to read php packages?
For a first step it would be totally ok, to extract the name and the licenses from the package.
IMHO this could not be so hard to implement, as the composer.lock file contains all the needed information.
{
    "_readme": [
        "This file locks the dependencies of your project to a known state",
        "Read more about it at https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies",
        "This file is @generated automatically"
    ],
    "content-hash": "08ca52f5eb5d5be4104ee3a5db00cc54",
    "packages": [
        {
            "name": "cweagans/composer-patches",
            "version": "1.6.5",
            "license": [
                "BSD-3-Clause"
            ],
            "require": {
                "composer-plugin-api": "^1.0",
                "php": ">=5.3.0"
            },
            "require-dev": {
                "composer/composer": "~1.0",
                "phpunit/phpunit": "~4.6"
            },
            "description": "Provides a way to patch Composer packages.",
        ...
        },
...
}

Sorry @kaystrobach I can't claim to be a contributor to this project anymore. Last time I checked, it was in the capable hands of @kdykeman. You might also reach out to @xtreme-shane-lattanzio @xtreme-vikram-yadav and @xtreme-lisheng-tai who have been the core maintainers lately.
It does, indeed, look like composer.lock contains the right kind of info. I'm glad to know GitLab is using LicenseFinder. Best of luck!

Thanl you for the explanation. I would provide a PR myself, but I never worked with ruby before 😪

@kaystrobach, PR #231 to "Add support for PHP via Composer" is out there, but has been languishing for a while. I was hoping somebody would jump in to help fix it up to align with some of the refactoring that's been done or submit a new PR. I'll start fishing around a bit more.

Nice have you seen thr generic approach idea as well? Maybe it makes sense to define a generic license information json format, which can be provided by composer directly or via a ugin

I definitely saw the generic approach idea as well - seems to make sense. It's probably quickest path to implement something in the current framework, and look at refactoring in the the longer term.

@kdykeman can i help you to get that done with sponsoring part of your time maybe? Would cost me too much time to finally dig into it to the full extend.

I'll try to take a look at this over the weekend.

@osis thank you, maybe the universal approach is the better longterm solution 👍

@osis @kdykeman I was able to take all the hard work from the past two PRs that were up for PHP support and get them working, tests and all in #589.

Nice!
On Thu, May 30, 2019 at 1:28 PM Zachary Knight<EMAIL_ADDRESS>wrote:

@osis https://github.com/osis @kdykeman https://github.com/kdykeman I
was able to take all the hard work from the past two PRs that were up for
PHP support and get them working, tests and all in #589
https://github.com/pivotal/LicenseFinder/pull/589.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pivotal/LicenseFinder/issues/518?email_source=notifications&email_token=AACUXWN3KUWQOKGCFLHOWQ3PX7B7LA5CNFSM4F67EGK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWSGGGQ#issuecomment-497312538,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACUXWNDOECXMYEEN3QPCWLPX7B7LANCNFSM4F67EGKQ
.


spring-cloud-gcp-starter-pubsub not shutting down

Hi,
I'm experiencing some issues using spring-cloud-gcp-starter-pubsub where the application hangs on shutdown. It sounds the same as this issue https://github.com/spring-cloud/spring-cloud-gcp/issues/60 which was closed when it wasn't able to be reproduced.
I have created a Spring CommandLineRunner Application that will publish messages to PubSub and then shutdown however it does not. I've provided the bare minimum to reproduce here https://github.com/danneville/spring-gcp-pub-sub-issue . Just the inclusion of the spring-cloud-gcp-starter-pubsub dependency causes the application to hang on shutdown. If you remove the dependency it shuts down immediately as expected.
This happens both when running the application in IntelliJ and on the command line.
I've provided the thread dump in the repo if this helps.
Please can you confirm if this is an issue or if I should be specifying something to gracefully shutdown?
Many thanks

Thanks for reporting the issue!
I was able to reproduce it using your sample app. We will take a look.

We identified the issue, will push a fix shortly.

@danneville This has been fixed in 1.2.0.BUILD-SNAPSHOT, but if using a snapshot version is not an option, you can close the thread pool like this:
@SpringBootApplication
public class SampleApplication implements CommandLineRunner {

    @Autowired
    @Qualifier("subscriberExecutorProvider")
    ExecutorProvider subscriberExecutorProvider;

    @PreDestroy
    public void shutdownExecutor() {
        this.subscriberExecutorProvider.getExecutor().shutdown();
    }

    public static void main(String[] args) {
        // ... original logic
    }
}

Excellent thank you @elefeint amd @dmitry-s for you quick responses.
I can confirm that this worked for me. I did also have to add the publisherExecutorProvider to get it to work for when I'm publishing messages.
    @Autowired
    @Qualifier("subscriberExecutorProvider")
    private ExecutorProvider subscriberExecutorProvider;

    @Autowired
    @Qualifier("publisherExecutorProvider")
    private ExecutorProvider publisherExecutorProvider;

    @PreDestroy
    public void shutdownExecutor() {
        this.subscriberExecutorProvider.getExecutor().shutdown();
        this.publisherExecutorProvider.getExecutor().shutdown();
    }

Thanks again


Hardcoded use of PASSWORD_BCRYPT

The Auth::hashPassword method is using a hard coded PASSWORD_BCRYPT when calling password_hash. While the current versions of password_hash (5.5 thru 7.1) only support two valid values PASSWORD_DEFAULT and PASSWORD_BCRYPT, and they both have the same value, this is not an issue. Hopefully this will change in PHP 7.2 with the stronger cryptography being added.  The php.net site indicates that PASSWORD_DEFAULT 'may' change with stronger cryptography, thus it should be the stronger/secure algorithm. I would suggest adding the 'algo' argument to $options as the 'cost' is. I can work on a pull request if you would like.

Hey @kenesa,
Yep you're totally right, this was something that's been nagging me for a while and I haven't had a chance to look at. I should be able to over the weekend if you can hold on, or if you'd like to submit a pull request I'd be more than happy to review it :)
My thoughts were that the Auth class should probably have a setAlgorithm() and getAlgorithm() pair that then gets passed into the password_hash etc function, but if you can think of a cleaner way please do, otherwise I'll get this patched over the weekend.
Thanks for the report!
Alex

Hello Alex,
My concern with a setter/getter for the algorithm is you are now using two different methods of configuration for password_hash(). Both the algo argument and cost options have the same importance, in my mind, to ensuring we have a secure password hash.
As for a clean way to address this, that is a little more complex. Without breaking backwards compatability, I would recommend:
        $defaultOptions = array(
            'algo' => PASSWORD_BCRYPT,
            'cost' => 8,
        );

    public function hashPassword($pass)
    {
        $algo = $this->options['algo'];
        $optn = array('cost' => $this->options['cost']);
        return password_hash($pass, $algo, $otpn);
    }

It has the benifit as totally plug-n-play with prior releases, yet allows the ability to override the algorithm when needed.
However, this still has a bit of an issue should the password_hash() internal method for generating a salt value is compromised, or there are more options made available in future releases of PHP. To fully solve this cleanly, would required breaking backwards compatability from a configuration point of view.
        $defaultOptions = array(
            'password_hash' = array(
                'algo' => PASSWORD_DEFAULT,
                'options' = array(
                    'cost' => 8,
                ),
            )
        );

    public function hashPassword($pass)
    {
        $algo = $this->options['password_hash']['algo'];
        $optn = $this->options['password_hash']['options'];
        return password_hash($pass, $algo, $optn);
    }

This method focuses the password_hash() configuration in a manner that does not limit any changes you might make to Auth configuration, and eliminates the need to make any changes until such time that the password_hash() signature changes.

Looking through the code, we actually don't return the options to the user at any point, so we could do anything we want internally to that array without worry. So you could do something like:
$defaultOptions = array(
            'algo' => PASSWORD_BCRYPT,
            'cost' => 8,
        );

    public function hashPassword($pass)
    {
        $optn = $this->options;
        $algo = $optn['algo'];
        unset($optn['algo']);
        return password_hash($pass, $algo, $otpn);
    }

That way the options array can have other values included within it without worrying about the algo cluttering it up.
Though it's just occurred to me that we may have missed a far more obvious solution. You're totally right, defining the algorithm is a vital part of the lib, so why not append it to the constructor?
public function __construct($name, SessionDelegate $session, StorageDelegate $storage, array $options = array(), $algorithm = PASSWORD_DEFAULT)

There's no BC break since we supply a default arg, and it allows users to change up what algo they use? How does that feel?


🎉 4.1.1

ℹ About this release

Version: 4.1.1
Type: patch
Last Release: 4.1.0 (5/28/2024, 6:33:00 PM) [?]
Commits to merge: 10 [?]

📦 Dependencies

Update semantic-release from ^23.1.1 to ^24.0.0
Update simple-git from ^3.24.0 to ^3.25.0

📦 Development Dependencies

Added @eslint/js ^9.7.0
Added typescript-eslint ^8.0.0-alpha.51
Update eslint from ^8.57.0 to ^9.3.0
Update eslint-plugin-jsonc from ^2.14.0 to ^2.16.0

:tada: This PR is included in version 4.1.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


isValidSignature can't actually verify signatures for external contracts

lets say contract X wants to verify an eip712 signature.
Now contract X would already have his own typed_structure which he uses to contract the digest hash.
So when this contract would call the smartaccount isValidSignature(digest...)
The verification will fail because the kernel isValidSignature calculates a digest for the digest.
I believe isValidSignature is supposed to be used to verify requests from other contracts and not signatures designated to the smartaccount.
https://github.com/zerodevapp/kernel/blob/31180268020830c4ef794f68b3bb60dac9ecfa05/src/Kernel.sol#L304

Ok i've figure that you in order to verify an eip signature you actually have to sign a wrapped version of the original digest.
This is really not standard and not supported easily by frameworks like ethers.
But i was able to make it work like that
// create the digest instead of signing it
const digest = _TypedDataEncoder.hash(
        yourContractDomain
        yourContractDomainTypes
       yourContractValues
      );

      // wrap the digest in eip712 domain
      // required for Kernel smart contract isValidSignature
      const wrappedDigest = utils.keccak256(
        hexConcat([
          "0x1901",
          _TypedDataEncoder.hashDomain({
            name: "Kernel",
            version: kernelVersion,
            chainId,
            verifyingContract: smartAccountAddress
          }),
          digest
        ])
      );
      signer?.signMessage(utils.arrayify(wrappedDigest));

actually, this is how this has to be handled, without wrapping the digest, it will face the signature replay issue if signer owns more than 1 smart contract wallet

i'd suggest adding this to the docs somewhere


host affinity backwards compatiblity

Fixes #226

@caseydavenport I need to fix a panic (that I plan to get to in the morning ☕ ) but you can start reviewing if you want.

this is what it looks like in etcd now:
$ etcdctl get /calico/ipam/v2/assignment/ipv4/block/<IP_ADDRESS>-26
{"cidr":"<IP_ADDRESS>/26","affinity":"host:host-A","strictAffinity":false,"allocations":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"unallocated":[],"attributes":[{"handle_id":null,"secondary":null}]}

@caseydavenport made those changes except inlining host, I'm still in favor of not inlining it for code readability PoV, but I can be convinced otherwise.

@caseydavenport made those changes including inlining "host:"
PTAL

OK looking pretty good.  A couple more comments - almost there!
I'm also a bit worried about the testing we should be doing on this.  Let's chat.


129017463: Fix the property names in scheduler to match the json properties passed by api server.

You seem to have a lot of whitespace issues and your line endings are just CR. Just something you may want to fix.

Merged


Feature to allow suppressing unsuccessful init error message

As you can read in https://github.com/m-m-m/util/issues/194 there are cases where one uses slf4j in general library code that is also used in command-line-interface (CLI) programs.
In my case I want to ship the CLI library without any logger binding for slf4j in order to give users the freedom to choose on their own. However the CLI library already contains CLI programs by itself. If you want to run them without additional dependencies you get a warm welcome from slf4j saying:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

In case of a CLI program this output is really undesired.
I tried to be constructive and provide a minimal invasive "fix" for the problem that allows to suppress this output by setting a system property slf4j.suppressInitError (I tried to follow your current code and naming conventions) to true.
You can also add a public static non-arg method to LoggerFactory that sets the system property to true for you if you like. Also you can think of a system property that enforces nop logger no matter what is on your classpath. But as stated before I wanted to keep the change and impact minimal so I hopefully have a high change to get this PR accepted and you see this as a helpful improvement to slf4j. Thanks in advance.

completely redone as master changed and merge was not possible anymore.

No reaction after 6.5 years?

Filing a jira issue would have helped this PR getting more attention as explained at the project's home page..
As you write, the PR is non-invasive which is good. However, for a CLI, adding slf4j-nop would work as well. As such, I am closing this PR without merging.

However, for a CLI, adding slf4j-nop would work as well. As such, I am closing this PR without merging.

This works if the users of the CLI library know about such things. However, users will try out the library and then see this SLF4J output messing the help page.  Unfortunately that is how life works. I can not include slf4j-nop myself as then other users that want to use a real logger writing to a file while the CLI is only producing basic output.

How about including slf4j-simple which Maven uses? It is still quite configurable.


Using Cubo to create Sentinel 5p data cubes

Hello,
I've been trying to use Cubo to download cubes from the Sentinel 5p collection available on the planetary computer:
https://planetarycomputer.microsoft.com/dataset/sentinel-5p-l2-netcdf
The download process works quite well by simply adapting the code snippet you provide in the documentation. But whenever I then try to apply the to_numpy() method to the resulting DataArray i get the rasterio ValueError "Can't read closed raster file". This doesn't happen when attempting to do the same with the sentinel-2 l2a collection.
Here's the code snippet I'm using:
import cubo
import xarray as xr
Not working
da = cubo.create(
lat=49.80,
lon=9.42,
collection="sentinel-5p-l2-netcdf",
bands=["no2"],
start_date="2021-01-01",
end_date="2021-01-01",
)
da.to_numpy()
Thank you in advance and best regards!

Hi @Frankie91!
Sorry I'm late answering. Two things:

The Sentinel-2 collection from MPC is open. Sentinel-5 is closed and therefore you need a token to access this collection. See https://planetarycomputer.microsoft.com/docs/concepts/sas/
Sentinel-5 is already provided as a netcdf. cubo uses stackstac as engine, so, it uses COGs to convert them into a multidimensional array. In the case of Sentinel-5, the data is already a multidimensional array. See https://stackstac.readthedocs.io/en/latest/api/main/stackstac.stack.html

I hope this solves your questions!
Best,
David


Update config.yaml

Config changes proposed in this pull request

For new organization members
I acknowledge that

[x] I have read and understood the Open Source Guidelines
[x] I agree to act accordingly (with due dilligence) to our guidelines
[x] I have no open questions regarding the topics covered (please delete the "open questions" section)

Open questions

Hi Richard, could you please commit with your baloise e-mail address?


Update TLS instructions to cover the change in default keystore type from JKS to PKCS12 in Java 9+

Problem
TLS instructions in https://github.com/apache/pulsar/blob/master/site2/docs/security-tls-keystore.md break in Java 9+ since the default keystore type is PKCS12 in Java 9+.
Prepare for supporting Java 9+ by updating the instructions.
Solution
Add -storetype JKS parameter to keytool commands in https://github.com/apache/pulsar/blob/master/site2/docs/security-tls-keystore.md .
Another possibility would be to document how the PKCS12 keystore can be used with Pulsar.
Additional context
default keystore type is PKCS12 in Java 9+

The related page has been removed from the latest(next) docs. Closed as invalid.


Remove remaining FIPS code

I don't know if you actually want this, but as mentioned in https://github.com/openssl/openssl/pull/436#issuecomment-150626011 I made a patch to remove most of the remaining FIPS code (there are still a bunch of error codes that I haven't removed).
This completely removes FIPS_mode_set(), FIPS_mode() and RAND_init_fips() from the public API. If this is not desirable, for backwards compatibility, these could be turned into no-ops.
Again, I don't know if this is something you want or not, but I already prepared the patch so might as well submit it here. Feel free to just close this PR if you want to keep the code.

Seems like the build failure was unrelated. Now the travis status is green.

After internal discussion, we trimmed down the list of what we're pulling out and it was pushed as commit #700b4a4


[SCB-727] Local generated schema and service center schema are different then print the diff content to the user

Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[x] Each commit in the pull request should have a meaningful subject line and body.
[x] Format the pull request title like [SCB-XXX] Fixes bug in ApproximateQuantiles, where you replace SCB-XXX with the appropriate JIRA issue.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Run mvn clean install to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Tips: when adding new commits to existing PR, please use commit message start with issue id, e.g.
[SCB-727] add unit test case
So that we can create a rebase and merge and we also known these commits are related.


restructure and document e2e "focus" targets

our e2e tests have evolved a lot since they were originally created and we currently miss consistent structure how the tests are run with user defined "focus" (as in `-ginkgo.focus").
this task is to define the structure and get the restructuring done (including documentation)
corner cases that are currently not well defined:

run selected devices with a subset of tests, for example:

without demo apps to just test plugin resources are OK
selected demo apps for a subset of devices in the same category (QAT Gen2 vs Gen4)

run operator based tests only for certain devices

@ozhuraki @hj-johannes-lee FYI. This is related to your e2e activities

this task is to define the structure and get the restructuring done (including documentation)

looks like there's going to be a need to have NFD deployed as part of the suite. One idea would be to run and Skip() tests based on node features.


Variation documentation updates

Updates to variation documentation. VEP docs still to come.

Please do not merge as additional updates to come. Thanks


MAC OS: failed to expose port <IP_ADDRESS>:6443 -> <IP_ADDRESS>:6443: listen tcp <IP_ADDRESS>:6443: bind: address already in use

I installed OpenShift local last week, ran through the setup and started crc successfully.
Came back this week, and everything works except crc start:
failed to expose port <IP_ADDRESS>:6443 -> <IP_ADDRESS>:6443: listen tcp <IP_ADDRESS>:6443: bind: address already in use
I don't have anything on <IP_ADDRESS>. My current address is <IP_ADDRESS>. So I don't know where this is coming from.
I already tried

crc stop
crc delete
crc cleanup
crc setup
crc start

No success

<IP_ADDRESS>:6443 -> <IP_ADDRESS>:6443 it means it is try to map 6443 port from host to VM and if the port is already in use then it will fail. Can you make sure you don't have 6443 port used by any other service on your mac.
sudo lsof -i :6443

@praveenkumar Thanks so much for responding!
So, I did try checking for other services using that port, and it brought back nothing.  This is why I opened a ticket.  The error is pretty clear, which makes it confusing when there aren't other listeners on that port.  Even after I deleted the instance a couple of times, I still got the error.
My mistake could have been using the netstat command, but I don't know why.  I've always used netstat.
Anyway I just rebooted my laptop.  I have Docker Desktop installed and it is set to automatically run - I also have the kubernetes module installed there.  I shut this down as well, although I don't have any evidence that this was the cause.
In any case, I'm up and running again!  Thank you!
crc     1229 kameroncole   15u  IPv4 0x13e7794b47673dff      0t0  TCP localhost:sun-sr-https (LISTEN)

I have Docker Desktop installed and it is set to automatically run - I also have the kubernetes module installed there.

@kc0olm looks like k8s on docker desktop might be the culprit because it also use 6443 port on host (iirc). Glad that you are able to make it work. I am closing the issue for now.


Comtain -> Contain

Fixing a spelling mistake I introduced in #9765

@tdykstra - Would you review the proposed changes? Thank you.

#sign-off

Thanks!


Added null check to some adapters and changed type definition

Some LSP requests lack null checking and are causing errors, so I fixed them.

I made the following changes:

Added null check (https://github.com/atom-community/atom-languageclient/commit/e20bba5a4fe06b4f1a24f2063b1a60fcd5da1514)
Fixed the type definition (https://github.com/atom-community/atom-languageclient/commit/85cc505a5c9999e4da044996aa49e436d32d017a)
Use the vscode-languageserver-protocol package for type definition (https://github.com/atom-community/atom-languageclient/compare/85cc505..d665159)

If you don't need the third change, reverting it will still work.

I think we were discussing this in https://github.com/atom-community/atom-languageclient/pull/132#discussion_r595580845
I'm not sure if it is better to through an error if the lsp returns something invalid or fail silently like this PR. Is null or undefined a valid return for .codeAction?

I think we were discussing this in #132 (comment)

This is different though.

This is different though.

How? Why are these checks necessary if null or undefined are not correct outputs of .codeAction anyway?

I meant the changes under lib/languageclient.ts which seem reasonable as they are using the original types.

I meant the changes under lib/languageclient.ts which seem reasonable as they are using the original types.

Ya I think those changes are good. I'm just not sure about null checks.

(some comment)

Currently, the vscode-languageserver-protocol module is used for type definition. In this PR, I also want to use it in the return value of the language-client method.
Since the return type is not exported directly from the module, I am using the generics of the function.

I used it as a reference for implementation
https://github.com/microsoft/vscode-languageserver-node/blob/d58c00bbf8837b9fd0144924db5e7b1c543d839e/client/src/common/client.ts#L83-L86

This will cause a type error if the wrong return type.

Removed null from the return value of the following request according to the type definition

completionItem / resolve
codeLens / resolve

Added null

textDocument/references
textDocument/documentHighlight
textDocument/documentSymbol
workspace/symbol
textDocument/codeAction
textDocument/codeLens
textDocument/documentLink
textDocument/formatting
textDocument/rangeFormatting
textDocument/onTypeFormatting
textDocument/rename

I think this implementation fits the spec, but you can leave null in the return value if you want to deal with invalid null checks outside the spec.

I'll review today or tomorrow


.env DB_name/DB_user can't create custom

Info:

Docker version ($ docker --version):   version 1.14.0, build c7bdf9e3
Laradock commit ($ git rev-parse HEAD): 004e4354aa5b84aa16c13fa1a5ac0a1002648500
System info (Mac, PC, Linux): PC
System info disto/version:

Issue:

changue the info of the mysql in the laradock .env and i compile it create the DB but not the user, yesterday also wasn't changue "default" the name of DB until i use a trick in a post i comment a line in docker-compose.yml , only can access with the default root/root and i don't find a solution it seen that the laradock doc is from less update version cause i cant find the lines in the docker-compose.yml that they mention.

Expected behavior:

create DB and DBuser with custom settings

Reproduce:

in the laradock .env replace data from MYSQL:
MYSQL_VERSION=8.0
MYSQL_DATABASE=tama_db
MYSQL_USER=tamatest
MYSQL_PASSWORD=secret
MYSQL_PORT=3306
MYSQL_ROOT_PASSWORD=root
MYSQL_ENTRYPOINT_INITDB=./mysql/docker-entrypoint-initdb.d

the line i comment in docker-compose.yml to make the DB use the name i want, yesterday work that way today in a new project it changue DB name but not create the user:
### MySQL Container ##...
... #rest of the code
volumes:
        # - ${DATA_SAVE_PATH}/mysql:/var/lib/mysql #commented line
        - ${MYSQL_ENTRYPOINT_INITDB}:/docker-entrypoint-initdb.d

Relevant Code:
// place a code sample here

Well i was totally wrong it dint create the DB at all


K8SPS-145:delete-ps-pods-in-order-finalizer

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

Test name
Status

auto-config
passed

demand-backup
failed

init-deploy
passed

gr-init-deploy
passed

config
passed

monitoring
passed

scaling
passed

semi-sync
passed

users
passed

service-per-pod
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/0e3e992ee40f697cff54a3323ed0d24448181ed3
image: perconalab/percona-server-mysql-operator:PR-159-0e3e992

Test name
Status

auto-config
passed

demand-backup
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

scaling
passed

service-per-pod
passed

config
passed

users
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/73d38660476d8a238642e6479f1c8e5604ac1422
image: perconalab/percona-server-mysql-operator:PR-159-73d3866

Test name
Status

auto-config
passed

demand-backup
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

config
passed

scaling
passed

service-per-pod
passed

users
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/2eb82051895cfa1efc10c5daa05ae1028e2cc10e
image: perconalab/percona-server-mysql-operator:PR-159-2eb8205

Test name
Status

auto-config
passed

init-deploy
passed

demand-backup
passed

gr-init-deploy
passed

scaling
passed

monitoring
passed

semi-sync
passed

users
passed

config
passed

service-per-pod
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/2e5e2d5f4c5d4cb9fc0bf8dad049235da9de8f7d
image: perconalab/percona-server-mysql-operator:PR-159-2e5e2d5

Test name
Status

demand-backup
passed

auto-config
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

scaling
passed

semi-sync
passed

config
passed

users
passed

service-per-pod
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/54fb52a82580082f4b38e654996e25987691393a
image: perconalab/percona-server-mysql-operator:PR-159-54fb52a

Test name
Status

auto-config
passed

init-deploy
passed

demand-backup
passed

gr-init-deploy
passed

scaling
passed

monitoring
passed

semi-sync
passed

users
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/18287e551034664a72f7af825554873038d9c3d8
image: perconalab/percona-server-mysql-operator:PR-159-18287e5

Test name
Status

demand-backup
passed

auto-config
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

scaling
passed

service-per-pod
passed

config
passed

users
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/4b4889aeded4a750aac5719774b26eaa49ddaed3
image: perconalab/percona-server-mysql-operator:PR-159-4b4889a

Test name
Status

demand-backup
failed

auto-config
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

scaling
passed

semi-sync
passed

users
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/e92511b519e2dd236ed06d1a609071fe4b4450cc
image: perconalab/percona-server-mysql-operator:PR-159-e92511b

Test name
Status

init-deploy
passed

auto-config
passed

demand-backup
passed

gr-init-deploy
passed

monitoring
passed

scaling
passed

semi-sync
passed

users
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/4537629a9d72dbf362da63d12c10a300923cfd71
image: perconalab/percona-server-mysql-operator:PR-159-4537629

Test name
Status

demand-backup
passed

auto-config
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

scaling
passed

semi-sync
passed

config
passed

service-per-pod
passed

users
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/2fbd3d7ab659a8db8406f4f6c1240576b4a177b2
image: perconalab/percona-server-mysql-operator:PR-159-2fbd3d7

Test name
Status

auto-config
passed

init-deploy
passed

demand-backup
passed

gr-init-deploy
passed

scaling
passed

monitoring
passed

semi-sync
passed

users
passed

config
passed

service-per-pod
passed

sidecars
passed

limits
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/3a5c22b54c16d9b8cbe5921a507cc86549e85bf9
image: perconalab/percona-server-mysql-operator:PR-159-3a5c22b

Test name
Status

auto-config
passed

demand-backup
passed

scaling
passed

users
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

sidecars
passed

limits
passed

config
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/f8aa9b623878ed88f86db05a35237c0597783e80
image: perconalab/percona-server-mysql-operator:PR-159-f8aa9b6

Test name
Status

auto-config
passed

demand-backup
failed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

scaling
passed

config
passed

sidecars
passed

limits
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/98a38d76316523b4f3bb006e869ca40baa7b7c92
image: perconalab/percona-server-mysql-operator:PR-159-98a38d7

Test name
Status

auto-config
passed

config
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

demand-backup
passed

service-per-pod
passed

sidecars
passed

limits
passed

scaling
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/98a38d76316523b4f3bb006e869ca40baa7b7c92
image: perconalab/percona-server-mysql-operator:PR-159-98a38d7

Test name
Status

demand-backup
failed

auto-config
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

config
passed

service-per-pod
passed

sidecars
passed

limits
passed

scaling
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/e50dab5e91210b470953be76d8e531fda56627f8
image: perconalab/percona-server-mysql-operator:PR-159-e50dab5

Test name
Status

auto-config
passed

demand-backup
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

scaling
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/6a271f67c9d18eec2c6bb8f1e6928497c5843fb2
image: perconalab/percona-server-mysql-operator:PR-159-6a271f6

Test name
Status

auto-config
passed

init-deploy
passed

demand-backup
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

scaling
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/5d6c9305ca1c696e9b21715ca90bbe23ee1048a4
image: perconalab/percona-server-mysql-operator:PR-159-5d6c930

Test name
Status

init-deploy
passed

auto-config
passed

demand-backup
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

config
passed

scaling
passed

sidecars
passed

limits
passed

tls-cert-manager
passed

users
passed

We run 13 out of 13

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/89a1ff3ac24226c489d76897ea00993b610f6f4a
image: perconalab/percona-server-mysql-operator:PR-159-89a1ff3

Test name
Status

init-deploy
passed

demand-backup
passed

auto-config
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

config
passed

scaling
passed

sidecars
passed

limits
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/2398337b4d08afa05319f18cd3f74073954a2532
image: perconalab/percona-server-mysql-operator:PR-159-2398337

Test name
Status

auto-config
passed

init-deploy
passed

demand-backup
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

config
passed

scaling
passed

sidecars
passed

limits
passed

users
passed

tls-cert-manager
passed

We run 13 out of 13

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/a88006859a67ac425fcad1df35c2be5ac5f5ea03
image: perconalab/percona-server-mysql-operator:PR-159-a880068

Test name
Status

auto-config
passed

demand-backup
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

scaling
passed

users
passed

We run 12 out of 12

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/c4fb81de9f145a979cd27ca09c3b6f09900968af
image: perconalab/percona-server-mysql-operator:PR-159-c4fb81d

Test name
Status

auto-config
passed

init-deploy
passed

demand-backup
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

config
passed

scaling
passed

sidecars
passed

limits
passed

users
passed

tls-cert-manager
passed

We run 13 out of 13

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/cc004bc2b11f28299f576c8f96f02c9fe3b59d95
image: perconalab/percona-server-mysql-operator:PR-159-cc004bc

Test name
Status

auto-config
passed

demand-backup
passed

scaling
passed

users
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
failed

semi-sync
passed

service-per-pod
passed

config
passed

sidecars
passed

limits
passed

tls-cert-manager
passed

We run 13 out of 13

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/2938f964f750659c9c520c0b674e751eb24036fe
image: perconalab/percona-server-mysql-operator:PR-159-2938f96

Test name
Status

auto-config
passed

config
passed

demand-backup
passed

scaling
passed

users
passed

init-deploy
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

sidecars
passed

limits
passed

tls-cert-manager
passed

We run 13 out of 13

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/2938f964f750659c9c520c0b674e751eb24036fe
image: perconalab/percona-server-mysql-operator:PR-159-2938f96

Test name
Status

demand-backup
passed

init-deploy
passed

auto-config
passed

gr-init-deploy
passed

monitoring
passed

semi-sync
passed

service-per-pod
passed

scaling
passed

config
passed

sidecars
passed

limits
passed

users
passed

tls-cert-manager
passed

We run 13 out of 13

commit: https://github.com/percona/percona-server-mysql-operator/pull/159/commits/9b3edf97f7cd5a765b304a9e20cbb3e38176bfd2
image: perconalab/percona-server-mysql-operator:PR-159-9b3edf9


Fix typo

Hell-sudo -> Hello-sudo

Hi @OofChair ! sorry for being so late, but thanks for your contribution!


xstools release xstools-0.1.31 doesn't work with pubsub 4 (with workaround)

The release 4.0.0 of pypubsub doesn't work with Python 2.7 and xstools-0.1.31, windows10
When installing xstools with pip, it installs current version of pubsub : pypubsub-4.0.0
When trying xstest.py, you get an error:
C:\Users\jancu>xstest
Traceback (most recent call last):
  File "C:\Python27\Scripts\xstest-script.py", line 11, in <module>
    load_entry_point('XsTools==0.1.31', 'console_scripts', 'xstest')()
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 565, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 2631, in load_entry_point
    return ep.load()
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 2291, in load
    return self.resolve()
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 2297, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "c:\python27\lib\site-packages\xstools\xstest.py", line 44, in <module>
    import xsboard as XSBOARD
  File "c:\python27\lib\site-packages\xstools\xsboard.py", line 28, in <module>
    from pubsub import pub as PUBSUB
  File "c:\python27\lib\site-packages\pubsub\pub.py", line 146
    def getDefaultPublisher() -> Publisher:
                              ^
SyntaxError: invalid syntax

workaround: install a 3.x version of pubsub:
C:\Python27>pip uninstall Pypubsub
C:\Python27>pip install -Iv https://pypi.python.org/packages/95/5a/1801be1a63af9250e79b8941a37b88e3ca0d660b880b9862fe9016ae6a3a/PyPubSub-3.3.0.zip
C:\Python27>xstest
Success: XuLA2-LX25 passed diagnostic test!
[pubsub_xstools.txt](https://github.com/xesscorp/xsconnect/files/732216/pubsub_xstools.txt)

I've attached a log of my actions from the prompt

Ran into the same problem. Thanks for the workaround!


Remove the version number of VuejS

I finally had the time to create a VueJS 2 implementation.
In the repo readme I added a link to tue VueJS 1 directive, thus, we can remove the version number from the gh-page.

Yeah. GG.
Thanks:


Allow listening to different interactions i.e focused by passing a MutableInteractionSource parameter

This is to observe interactions in the text field i.e pressed

You can add onFocusChanged and listen when the textfield's focus changes:
val context = LocalContext.current

DPhoneNumberTextField(
      modifier = Modifier
                  .fillMaxWidth()
                   .onFocusChanged {
                        if (it.isFocused) {
                              Toast.makeText(context, "Focused", Toast.LENGTH_SHORT).show()
                         }
                   }

Closing this as there is nothing that needs to change on the lib


TFRS - Transactions entered through the Historical Data Entry feature are being given a future effective date

Describe the task
A clear and concise description of what the task is.
Purpose
The reason why this task is needed and/or what value it adds.
Acceptance Criteria

[ ] first
[ ] second
[ ] third

Additional context

Add any other context about the task here.
Or here

Combined both bugs into single card as they may be related


HOTT-954: Expose links data

Jira link
HOTT-954
What?
I have added/removed/altered:

[x] Added the Scheme links to the /rules_of_origin_schemes endpoint
[x] Added the SchemeSet links to the /rules_of_origin_schemes endpoint

Why?
I am doing this because:

We want to show these links on the frontend

Are deploys broken because of the partial ECR move?


Camera asking again 3 times after photo is clicked on rotate

I am facing this issue when the phone is rotated during camera is already on. After saving the image it keeps asking again for like 3 times.
In the plugin, I tried adding the following line at beginning of execute and it didn't work.
this.cordova.getActivity().setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);

And in Cordova project, following is already present, indicating the problem may be inside the scanlibrary used in this project.
<activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" android:label="@string/activity_name" android:launchMode="singleTop" android:name="MainActivity" android:theme="@android:style/Theme.DeviceDefault.NoActionBar" android:windowSoftInputMode="adjustResize">
    <intent-filter android:label="@string/launcher_name">
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

I was able to reproduce this. Nice catch! I will look into this and get back to you as soon as possible.

This issue seems to be partially fixed, it doesn't ask again, but camera icon is always in portrait and images are always in landscape modes.

The issue seems to be completely fixed for me after testing on S7 Edge. The camera and the scanned image are reacting to orientation change exactly as expected. Closing this issue for now. Let me know if you are having troubles with it still. If you are having problems please post a detailed description of the issue, since it will be hard to test on my side.

@Varun-garg New Update fixes this issue completely. Just letting you know.
Cheers,
Chris
Neutrinos

Hey chris, thanks a lot for fixing it. :smile:


fix(chat): fix large right padding (Issue #1601)

Description:
paddings on request form should comply with
Issues:

Issue #1601

UI changes
Before:

After:

Checklist:

[x] the pull request name complies with Conventional Commits
[x] the pull request name starts with fix(<scope>):, feat(<scope>):, feature(<scope>):, chore(<scope>):, hotfix(<scope>): or e2e(<scope>):. If contains breaking changes then the pull request name must start with fix(<scope>)!:, feat(<scope>)!:, feature(<scope>)!:, chore(<scope>)!:, hotfix(<scope>)!: or e2e(<scope>)!: where <scope> is name of affected project: chat, chat-e2e, overlay, shared, sandbox-overlay, etc.
[x] the pull request name ends with (Issue #<TICKET_ID>) (comma-separated list of issues)
[x] I confirm that do not share any confidential information like API keys or any other secrets and private URLs

/deploy-review


Add Trino credentials to the secret

In order to run the create_results.ipynb through kubeflow pipelines with Elyra, Trino credentials should be available to the notebook. How can we add the JWT tokens to the existing Openshift secret? Is there a better workflow to address this use case?

Are there other issues that address this and that can be added here to track?

@Shreyanand not sure what you are asking for. Are you asking for other issues with the same problem? or other issues that resolved the same problem?

@Shreyanand as far as I'm aware we don't have such an issue


Add fibonacci sequence using recursion in python

Implemented fibonacci sequence using recursion

Hi @HarshCasper this is my first contribution to this repository. One of my checks is getting failed, can you please point out the mistake in my commit.

Cool!
I'll merge this :) Can I just make a request? Would you be willing to push your code further by adding other ways of obtaining F(n) in Python, for example, without using recursion, or using matrices, or using Binet's formula to calculate F(n) :)
Thank you very much for your contribution!
@all-contributors please add @Equinox-13 for code

Cool!
I'll merge this :) Can I just make a request? Would you be willing to push your code further by adding other ways of obtaining F(n) in Python, for example, without using recursion, or using matrices, or using Binet's formula to calculate F(n) :)
Thank you very much for your contribution!
@all-contributors please add @Equinox-13 for code

Yes, Hopefully in my future contributions
Thank you :) @ricardoprins


Finish the "interrupt" branch, merge back to master as 4.0.0

There is work in progress code, test it on both FreeBSD and Linux. Use a sane API (signal() is weird/cumbersome).

Bonus: show the last second of the minute by itself (so no more 2-second delay at the end of the minute).


Unable to set manual gasPrice

https://github.com/curvefi/curve-js/blob/48690999beffe59968b9ec0c03acd556b6ad029d/src/curve.ts#L426
updateFeeData() is overriding the manual gasPrice or EIP 1559 maxFeePerGas and maxPriorityFeePerGas which is set in the init() as
await curve.init('JsonRpc', {url: providerUrl, privateKey} , { gasPrice: 400, chainId: 137 );
Here the gasPrice is redundant as before calling any function like await curve.exchange(tokenFrom, tokenTo, amount);
there is an internal call to updateFeeData() https://github.com/curvefi/curve-js/blob/48690999beffe59968b9ec0c03acd556b6ad029d/src/pools.ts#L1550 which overrides the Fee Data which it gets from the this.provider.getFeeData() which is not always desired.

But there is a condition
this.options.gasPrice = this.feeData.gasPrice !== undefined ?
                ethers.utils.parseUnits(this.feeData.gasPrice.toString(), "gwei") :
                (feeData.gasPrice || await this.provider.getGasPrice());


Add preview packages

App

[ ] Admin
[ ] Summon
[ ] Hub
[X] Toolbox

Feature Type

[X] New Feature
[ ] Enhancement

Feature
Offering to implement auto-publishing PR packages, using a Github Action I  built https://github.com/UseKeyp/publish-pr-packages

Screenshots and Context
No response

@pi0neerpat How does this work?

When a PR is opened, the package is built and published automatically. This allows you to test locally, without having to use yarn-link


Dbz 3974 schema change doc updates

DBZ-3974
This change adds missing information to the MySQL connector doc about the tableChanges field in schema change messages and also updates the Db2, Oracle, PostgreSQL, and SQL Server connector docs for consistency.
Changes tested in a local Antora build.

I noticed that a bunch of commits had been added to master after I submitted the PR, so I rebased my branch. Now I'm seeing the message that there are conflicts. Let me know if I need to adjust anything on my end.

@roldanbob, yeah, there's way too many commits in this PR. Can you rebase this one to the latest master and then force-push to this PR's branch? There should only be commits attributed to DBZ-3974 part of it.


Editor crash when minimizing on Windows (crash in VulkanContext::prepare_buffers)

Godot version:
5f1107a
OS/device including version:
Windows 10
Steps to reproduce:

Minimize editor

[0] vk_optimusGetInstanceProcAddr
[1] vkGetInstanceProcAddr
[2] VulkanContext::prepare_buffers (x:\inne\godot\source\godot\drivers\vulkan\vulkan_context.cpp:1228)
[3] RenderingDeviceVulkan::prepare_screen_for_drawing (x:\inne\godot\source\godot\drivers\vulkan\rendering_device_vulkan.cpp:6692)
[4] VisualServerViewport::draw_viewports (x:\inne\godot\source\godot\servers\visual\visual_server_viewport.cpp:452)
[5] VisualServerRaster::draw (x:\inne\godot\source\godot\servers\visual\visual_server_raster.cpp:114)
[6] Main::iteration (x:\inne\godot\source\godot\main\main.cpp:2139)
[7] OS_Windows::run (x:\inne\godot\source\godot\platform\windows\os_windows.cpp:661)
[8] widechar_main (x:\inne\godot\source\godot\platform\windows\godot_windows.cpp:162)
[9] _main (x:\inne\godot\source\godot\platform\windows\godot_windows.cpp:186)
[10] main (x:\inne\godot\source\godot\platform\windows\godot_windows.cpp:196)
[11] __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
[12] BaseThreadInitThunk
-- END OF BACKTRACE --

I am unable to reproduce this, is it still a problem?

Yes, just tried with 73262c0

This is windows only I believe and I'm still experiencing it on master

At first glance it seems that w->swapchain is being set to NULL after the if statement check.
It would seem that there might be some form of thread fighting happening here, but I dont have any experience with the vulkan stack and windows context to know whats going on.

I managed to breakpoint right before the call to fpAcquireNextImageKHR.

I confirmed that the swapchain is indeed NULL before the call to fpAcquireNextImageKHR.
I set a breakpoint at 1221 in vulkan_context.cpp, where the swapchain is out of date due to a window resize.
this calls into _update_swap_chains(), which at line 839 returns OK without having allocated a swapchain due to the window width and height being zero. This causes the next iteration of the do-while to call fpAcquireNextImageKHR with a nullptr.

Seems fixed in bc23899


Document or provide mechanism to set --endpoint like aws cli

It would be useful if awless had a mechanism to set the endpoint (and region for signature reasons) to be able to use awless against localstack (https://github.com/localstack/localstack) for testing.
For instance, this works with aws cli:
export AWS_ACCESS_KEY_ID=localstack
export AWS_SECRET_ACCESS_KEY=localstack
aws --endpoint-url=http://localhost:4576 --region us-east-1 sqs create-queue --queue-name testq
{
    "QueueUrl": "http://localhost:4576/queue/testq"
}

Where awless appears to not accept --endpoint or --endpoint-url:
awless list queues --endpoint-url http://localhost:4576 --aws-region us-east-1
... usage info/error...
awless list queues --endpoint http://localhost:4576 --aws-region us-east-1
... usage info/error...
awless list queues --aws-endpoint http://localhost:4576 --aws-region us-east-1
... usage info/error...
awless list queues --aws-endpoint-url http://localhost:4576 --aws-region us-east-1
... usage info/error...

Am I missing something in the docs or is this not an available feature?  I did not find a documented feature looking through the CLI docs/help output, while it looks like this may be configurable at the code level.

Thanks for the suggestion. Indeed, we are looking at localstack for testing purposes as well.

It would be awesome to have the support

Are there any plans to implement this ?

Also interested in this. Thanks.


Add support for screenshots

You can hit Control-P to dump the framebuffer's contents to a BMP file.
I picked Ctrl-P almost completely randomly, there's probably a more sensible choice.
I also wonder if the directory into which the screenshots are written should be configurable by the user.

I don't know SDL but is there perhaps a routine to dump it as PNG instead?  Much smaller and more cross platform

That's fair. I'd prefer to write PNG as well -- but SDL2's base library only provides this BMP writer.
If we want to support PNG then we'd have to bring in SDL2_img, or use libpng directly, I suppose (either way we'd be introducing a whole new dependency). Otherwise we could most likely get away with 'stb_img' https://github.com/nothings/stb/blob/master/stb_image_write.h -- That way, we can still claim that SDL2 is the only dependency like it says in the README.

OK, how about this version? I'm using the STB PNG writer

I like that you tried to keep the dependencies minimal but it's too bad there's no PNG writer in SDL itself already.
It's up to the maintainers to decide if the stb_png header addition is acceptable as a (small) new dependency. Otherwise I'm not opposed to the BMP writer, I just prefer PNGs

I suppose it doesn't make much sense to save screenshots to disk when you're interacting with the emulator in a web browser?
(I actually have no idea how Emscripten works)

I suppose it doesn't make much sense to save screenshots to disk when you're interacting with the emulator in a web browser?
(I actually have no idea how Emscripten works)

The screenshots would actually have landed on the wasm build's version of the host filesystem (a construct within the browser's memory).  Currently there's no way to access those files from the host side, but rather from within the emulator itself.


[Story] Add delete note

Epic: #18
Description
As a user I want to be able to delete notes, so I can keep them organized and current.
Tasks

[x] Create delete note in note service.
[x] Create delete note page.

Created delete notes as part of the notes feature implementation, see:
https://github.com/KinaUna/Examplium/tree/master/Documentation/Code/Notes


Provide new baseline checkpoints

Thanks, I will merge it once the new checkpoints are uploaded to s3.


Refactor RssLogsController

Refactors index action and private method show_selected_rss_logs
Fixes various metric offenses
Delivers Pivotal #184317455

Manual Test

Go to the Activity Feed, http://localhost:3000/
Try the various tabs (Observations ... News)
After selecting one of tabs (Ex: Names), click Submit, select Make This My Default.
Check all the tab checkboxes, click Submit
It should show everything.
http://localhost:3000/
It should show only your default type(s) of logs.

Coverage: 93.352% (+0.006%) from 93.347% when pulling 835b76bef6eecb9128d6e4a40ecb6ce95e944413 on jdc-rss_controller-refactor-184317455 into f360ef27af6bb5ca2c8746d66741b48e56489784 on main.

Nicely done.  Thumbs up.

@mo-nathan