How to create two output files using nunit 3

I am getting three output xml files as result in nunit 3 by running the command nunit3-console "my dlls" --result: "my ouput path".
I need to combine the three results of the files into one xml file. SO I would like to do as

nunit3-console "dll 1" --result: "path1" %and common xml file%.
nunit3-console "dll 2" --result: "path2" %and common xml file%.
nunit3-console "dll 3" --result: "path3" %and common xml file%.

How to achive this via nunit command. Please suggest solution for me.

I think you may have posted to the wrong project? CropCircle doesn't have anything to do with nunit.


Translating a cell

Hi Heitzmann,
I also really appreciate this great module. Lovely Work. Thanks you very much!
In my project I also read loads of cells and place them with gdspy. The imported cells are not neccessary nicely centered around an meaningfull origin. Also they have several sub-references and loads of polygons atc. These Cells are then again referenced at different locations with different rotations.
What is the best way to move all contents of a cell with out adding another hierarchical layer (Cell reference). Like centering them nicely before they get referenced again.
Moving all contents of the cell (Polys, Labels, References etc.) sounds like a solution but is rather slow.
Adding an intermediate cell and then flattening again removes hierarchy.
Can you think of a nice solution ?
Best regards + Thank you

Hi @vindi-pix,
Indeed translating every element or flattening a new cell would be very slow. Unfortunately there is no other option: it is either translating each element (polygon, path, label and references) or creating a new cell with a single reference at the desired position.
If I understand your issue, the problem is that your existing cells have strange origins, so when you place them in your layout, you have to inspect the cell you're referencing to find out how to place it, correct?
One possible solution for this case is to create a dictionary of corrections, so that when you reference a cell, the correction can be directly applied. Of course, to create the dictionary, you'll have to go through each possible cell you'll want to use and inspect it, but you're already doing it anyway. What I mean is something like this:
correction = {
    "CELL1": numpy.array((some_x_pos, some_y_pos)),
    "CELL2": numpy.array((another_x, another_y)),
}

ref = gdspy.Reference("CELL1", origin=(desired_x, desired_y) + correction["CELL1"])
main_cell.add(ref)

Hi @heitzman, thanks for the quick answer.
Yes, I also used the correction approch but then rotation is applied around original center.
Or is this somehow parametric ?
I mean it is possible to nicely center them before importing or shifting the content. I was just unsure, whether I did oversee this function ;)
Best regards

You're right, rotation is applied around the original center... you'll have to compensate for that...

I did. Everything worked out nicely. Thanks for your help + making gdspy ;) . Cheers


Fix job and level capture missing from Regexes.addedCombatantFull

Missed job and level capturing groups for Regexes.addedCombatantFull.
I'm still working through converting the regexes for #1387 to use Regexes functions.

Another thing I'm running into issues with is this:
      AbilityCode: '[0-9A-Fa-f]{1,4}',

This regex doesn't match item uses, e.g. this line:
[23:00:59.384] 15:12345678:Some One:20FB57E:Item_Fb57e:12345678:Some One:E800010E:300000:0:0:0:0:0:0:0:0:0:0:0:0:0:0:117462:117462:10000:10000:0:1000:99.71765:111.1925:-5.960464E-08:-2.182744:117462:117462:10000:10000:0:1000:99.71765:111.1925:-5.960464E-08:-2.182744:0000501C

Re: ability code.  Maybe change all the captures to be .*? in regexes.js?  I think I did that for almost everything in netregexes.js.  I tried to make \y{Name} be just .*? in general rather than the monster that it is, but it broke a few things.
Alternatively, make it more complicated to support Item_etc as well?
What do you think?

It could just be [0-9a-zA-Z]{1,8} instead. I'm just not sure if it was done with 1-4 for a reason.

It could just be [0-9a-zA-Z]{1,8} instead. I'm just not sure if it was done with 1-4 for a reason.

Yeah, that's also reasonable! Probably the most minimal change.

I tried to make \y{Name} be just .*? in general rather than the monster that it is, but it broke a few things.

That should work without issues as long as the regexes using it do a full line match. Do you have specific examples of where it broke?

I tracked this back to https://github.com/quisquous/cactbot/commit/ea1cff1a798d59ce228354ed248145b70f7f6d86 which seems like it should be fine to un-revert now, since everything's using Regexes that references \y{Name} as far as I can see, with the exception of https://github.com/quisquous/cactbot/blob/master/ui/raidboss/raidemulator.js#L62 which shouldn't have any issues with .*?. I don't think it's in scope for this PR, but might be something you want to look at or it's something I can submit a separate PR for.
Either way, I've amended the commit with the 1-8 change, so this should be good to merge now.

Alright. Hopefully now I've actually found all the missing capture groups and such. I've passed these through about 6.1 million log lines now, for content from 2.0-latest, normal dungeons, trials, and raids.
Only thing I couldn't really test was open world content since I don't usually bother running ACT for that.
If I find anything else missing I'll just open a new PR for it.


Add DebugPrefixMap remapping back to module creation

@adrian-prantl This was accidentally removed in commit 10004edf49e39f98f2c7498f9c15a79d364eb05c.
EDIT: Also would be great to merge this into swift-5.0-branch (minor update) if possible. Thanks!

We'll need to add a testcase for this or else this will break again.

True, I'll try to add one.

@adrian-prantl done, tested added

Nice. Could you please open a separate PR making the same change on the master branch? There is no automerger from 5.1 -> master.

Done in https://github.com/apple/swift/pull/23628

@swift-ci test and merge

Also would be great to merge this into swift-5.0-branch (minor update) if possible. Thanks!
Could you please create a pull request and add me and @fredriss as a reviewer? Again, no promises.

@swift-ci test and merge

Looks like it failed due to an unrelated Linux error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-swift-5.1-branch/swift-corelibs-foundation/TestFoundation/TestThread.swift:65: error: TestThread.test_threadName : XCTAssertEqual failed: ("Thread2-1") is not equal to ("Thread2-2") -
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-swift-5.1-branch/swift-corelibs-foundation/TestFoundation/TestThread.swift:65: error: TestThread.test_threadName : XCTAssertEqual failed: ("Thread2-1") is not equal to ("Thread2-2") -
Test Case 'TestThread.test_threadName' failed (0.001 seconds)
Test Case 'TestThread.test_mainThread' started at 2019-03-29 18:09:21.529
Test Case 'TestThread.test_mainThread' passed (0.0 seconds)
Test Case 'TestThread.test_callStackSymbols' started at 2019-03-29 18:09:21.529
Test Case 'TestThread.test_callStackSymbols' passed (0.001 seconds)
Test Case 'TestThread.test_callStackReurnAddresses' started at 2019-03-29 18:09:21.530
Test Case 'TestThread.test_callStackReurnAddresses' passed (0.0 seconds)
Test Suite 'TestThread' failed at 2019-03-29 18:09:21.530
	 Executed 6 tests, with 2 failures (0 unexpected) in 0.007 (0.007) seconds

@swift-ci test and merge


fix issue 15991 - std.datetime.StopWatch is not @nogc

Just adding a bunch of @nogcs, looks good to me.

👍

++LGTM

By the way...I pity the guy who'll have the bad idea to take "nogc" as nickname on GH.

Auto-merge toggled on


Avoid sudo chown for tilt up

tilt up is great, but compile gets stuck at sudo chown.
I think copying instead of moving is fine (18MB).

works great!


VB-1763 - script to update visits for Cardiff, Preston and Wandsworth

VB-1763 - script to update visits for Cardiff, Preston and Wandsworth to ensure visit times to match the timetables provided by each prison.
What does this pull request do?
Updates visits migrated for the 3 new prisons to be onboarded to update the visit timings with the data in the session templates.
What is the intent behind these changes?
Keep visit data in sync with session templates to allow these visits to be updated.

WIP - Adding a PR for initial review. Will do some more checks on Live before merging it.

Looks good to me, I would have used a join instead of a subquery but as this is practically throw away code it does not matter... looks like sound SQL

@AledWEvans - Removed the WIP from PR. Could you please approve.

THis was tested on preprod and looking at the data we can run these scripts in Prod now.


[IntelliJ Plugin] Code folding regions are not created for record types

Description:
Code folding regions are not created for the record definitions in the latest ballerina intellij plugin version.
Steps to reproduce:
Affected Versions:
plugin version: 0.991.0
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Closing since fixed by #16362.


Does not work when app has a separate process (i.e. GPU Helper)

There are apps that use additional processes for GPU acceleration (i.e. Microsoft Teams, Slack, Chrome) where this script doesn't really help. It is however pretty easy to fix this, as these processes are usually contained within <something GPU Helper>.app files, so it's just a matter of selecting these too.
As an example, Google Chrome uses an additional GPU Helper process:

Setting the checkbox Prefer external GPU for just the Google Chrome.app does not do the trick, because the actual GPU acceleration is ran by the other process. What has worked for me was manually changing that process' checkbox for external GPU preference. Having tested it with other apps, all of these seem to follow the pattern bellow:

Essentially, it's a matter of getting into the application's contents folder and scanning for *.app files.
I would be happy to work on this when I have time, but that might not be for a while. Given how simple this is I would be happy for someone else to take over, should they have the time.

I can take a look at this as it's a bit annoying.
Do you think it's common sense we should only add the GPU helper process for now in chromium and electron apps or adding any other .apps would be the best approach?
I think the script will have to run again on each app update?


Making User Profile better with some errior validation and adding new features

The user profile Activity currently doesn't have proper errors/toast to show which can definitely increase user experience

hey, @rahulsain can I work on it under the hacktoberfest label?

What errors or toast exactly you want to add?

What errors or toast exactly do you want to add?

I actually have many whichever you want me to work on I can

if you click on reset password and if it doesn't have any password/logged in then it should give a toast to it
direct click on the user profile photo rather than going into change profile and change it.
edit profile already has texts and having some texts in the edit text field is not good as the person has to remove the text  and then add it
and when you click on save there are also some things I would like to change according to this
verify email also has the same thing as  reset password

There are toasts for no 1 and 4.
No need for no 2
No 3 is required when we edit the fields from second time onwards
On Tue, 5 Oct, 2021, 1:40 pm Dhiraj Chauhan, @.***>
wrote:

What errors or toast exactly do you want to add?
I actually have many whichever you want me to work on I can

if you click on reset password and if it doesn't have any
password/logged in then it should give a toast to it
direct click on the user profile photo rather than going into
change profile and change it.
edit profile already has texts and having some texts in the edit
text field is not good as the person has to remove the text and then add it
and when you click on save there are also some things I would like to
change according to this
verify email also has the same thing as reset password

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rahulsain/SharedNotes/issues/29#issuecomment-934171024,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMB2LNKDNR3K3SKJJZ74PQTUFKXITANCNFSM5FJZQNHA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

d when we edit the fields from s

but it st

There are toasts for no 1 and 4. No need for no 2 No 3 is required when we edit the fields from second time onwards
…
On Tue, 5 Oct, 2021, 1:40 pm Dhiraj Chauhan, @.***> wrote: What errors or toast exactly do you want to add? I actually have many whichever you want me to work on I can 1. if you click on reset password and if it doesn't have any password/logged in then it should give a toast to it 2. direct click on the user profile photo rather than going into change profile and change it. 3. edit profile already has texts and having some texts in the edit text field is not good as the person has to remove the text and then add it and when you click on save there are also some things I would like to change according to this 4. verify email also has the same thing as reset password — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMB2LNKDNR3K3SKJJZ74PQTUFKXITANCNFSM5FJZQNHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

no, but it still lets people click on the button and the dialog box opens it should directly say on click
why letting people do write all fields and then show a toast

There are toasts for no 1 and 4. No need for no 2 No 3 is required when we edit the fields from second time onwards
…
On Tue, 5 Oct, 2021, 1:40 pm Dhiraj Chauhan, @.***> wrote: What errors or toast exactly do you want to add? I actually have many whichever you want me to work on I can 1. if you click on reset password and if it doesn't have any password/logged in then it should give a toast to it 2. direct click on the user profile photo rather than going into change profile and change it. 3. edit profile already has texts and having some texts in the edit text field is not good as the person has to remove the text and then add it and when you click on save there are also some things I would like to change according to this 4. verify email also has the same thing as reset password — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMB2LNKDNR3K3SKJJZ74PQTUFKXITANCNFSM5FJZQNHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

no, but it still lets people click on the button and the dialog box opens it should directly say on click
why letting people type all fields and then show a toast
the same thing is when we click on change profile after filling all the data it shows u need to be registered first, its better to show it when they click if the change is not gonna happen

I have implemented that way because in the future users have to log in to access.
That's why it is easier to maintain the code without changing much

okay I understand your implementation, so are there features that you recommend I should work on
I would love to contribute, thanks :)

I have implemented that way because in the future users have to log in to access.
That's why it is easier to maintain the code without changing much

okay I understand your implementation, so are there features that you recommend I should work on I would love to contribute, thanks :)

Do you have knowledge of storing audio video type of files to some database (free basically)

I have implemented that way because in the future users have to log in to access.
That's why it is easier to maintain the code without changing much

okay I understand your implementation, so are there features that you recommend I should work on I would love to contribute, thanks :)

Do you know about storing the audio-video type of files to some database (free basically)

no sorry I currently don't have any knowledge about that :/


Expose luaH_clear and luaH_clone in the C API

I find it troublesome that clearing a (large) table is faster from Lua code than using the C API. :) Should the internal functions luaH_clear and luaH_clone be exposed in the C API?

It would be easy to add but the reason we haven't done that in the beginning is that the need never came up in bindings that we were aware of. Is this more of a theoretical concern, or are there cases where C code would need to clear or clone a table?

We have utility functions for table clear & copy in our Lua extensions library that we're using in a couple of places. These currently use lua_next. A typical use case for clear is events, where we need to pass a large amount of arguments from C++ to Lua. We pass these arguments in a table because we don't want to break the function signature when adding new arguments, and also because passing a large number of arguments is too messy. For efficiency we reuse the same tables to avoid mem allocs at runtime. Basically the C++ code grabs an existing table, clears it, fills the args and calls Lua with the table. Not all events have the same structure, so we need to clear any previous values first.
(This obviously has the vulnerability that you may not stash the table anywhere on Lua side, since the contents of the table will be wiped out soon. A small price to pay for avoiding mem allocs.)
We have a performance budget of 1 ms per frame for all Lua code, so we're always looking for improvements. That said, I wouldn't expect huge gains from a faster table clear...
The use cases for table clone are quite specific. One of them is copying script environments when we patch script state during live updates. But that certainly is not a performance critical code path by any means. But if clear is added, perhaps adding clone makes sense?
Another point I'd like to make is completeness. It's valuable to be able to do all the basic operations that you can do with Lua on tables and other values also using the C API. (Of course, I can already clear/copy any table by iterating it myself, but you get the point :))
So, not the end of the world if these are not added, but would be nice to have.

Mhm. Clear for table reuse makes sense, as you note it can be dangerous but it's fundamentally up to the application. Just to make sure, when you say "copy", you mean the same semantics as luaH_clone, which is to say you're producing a new identical version of the table object, not copying fields between two tables?
Overall if there's use cases for this that are perf-sensitive then it makes sense to add this. We added lua_clonefunction recently so I suppose something like lua_cleartable / lua_clonetable would work.
I did want to mention that if you wanted the absolute fastest path wrt reuse of a table for bindings, you'd want to actually keep reusing the same table with the same shape and simply overwrite the fields. This will make sure that there's no time spent building up the table structure (which, for a table that is repeatedly cleared, doesn't involve extra allocations but does involve more work than strictly necessary). Of course, for this to work you'd need to make sure that each binding point uses a separate version of the table object so that you don't need to erase keys from other APIs, and can simply write the fields over.

Just to make sure, when you say "copy", you mean the same semantics as luaH_clone, which is to say you're producing a new identical version of the table object, not copying fields between two tables?

Ah, sorry, I had forgotten the details. You're right, we're copying the table, not cloning in this case. And even if we were truly cloning, it wouldn't be a strong case for adding cloning support to the API because performance is irrelevant in this context.

I did want to mention that if you wanted the absolute fastest path wrt reuse of a table for bindings, you'd want to actually keep reusing the same table with the same shape and simply overwrite the fields.

Yeah, this is something I have also thought about. We haven't implemented this yet, mainly because there are so many different shapes these event tables can have and managing the preallocated tables for each case is a bit messy. So for now we've taken the simpler approach and just reuse the same table for all events, but maybe I will re-evaluate this at some point.
So, we'd happily take lua_cleartable at least. The need for lua_clonetable may arise in the future but hard to say for sure...
Should I make a pull request? If so, should I add just clear or both?

Let's just add clear for now, just to make sure that for all C APIs we have clear use cases. On a somewhat unrelated note we'll add a faster iteration API for C code this week which would be a good replacement for lua_next for code that does need to iterate through tables.


⚠ Samsung has degraded performance

In d6a4ea8, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2728 ms

Resolved: Samsung performance has improved in 15d8b24.


When will microk8s 1.29 be added to the latest/stable snap?

The 1.29/stable was released nearly a month ago (though I understand everyone is busy with the holidays). Is there a timelime as to when the latest/stable snap will be updated to 1.29?

Currently I would not recommand to change to v1.29/stable. There is still an issue open 4361

Ah, so there is a larger bug left. Sure, I'll wait until that is fixed.


Feature request: embed assets so MH can be used without an active internet connection

I was trying out MailHog while on travel and I noticed that the Web UI wasn't loading correctly. I think that, given its important role in testing locally, MailHog should be able to work when downloading of remote assets isn't possible or it is difficult.

Awesome idea :+1:


Provide "high watermark" allocator for PX4

As part of #236 we need to provide a heap allocator that has some specific requirements for px4. @pavel-kirienko or @davids5 should have the requirements.

The high-level business requirement is to make PX4 maintainers happy.
We have empirically established that the following implementation is likely compatible with the business requirement:
https://github.com/UAVCAN/libuavcan/blob/master/libuavcan/include/uavcan/helpers/heap_based_pool_allocator.hpp
On the technical level, besides the obvious allocate/deallocate we also need shrink() which free()s all blocks that are not currently in use. This is useful because certain procedures such as firmware update may temporarily raise the watermark considerably, leaving the UAVCAN process with memory it no longer needs.


Connection impossible

We have written the needed data into your clipboard because it was too large to send. Please paste.

Hey @IzusaE, thanks for reaching out to Live Share! Sorry about the issue you're having. Could you please add more information about how to reproduce the issue and attach the logs? You can access your logs via the Live Share: Export Logs command in the command palette.

Closing this due to inactivity and a lack of actionable information. Please re-open this issue if you’re still encountering a problem. Thanks!


feat: declarative builder v2

supersedes #5932
Introduces a declarative node builder that configures the node step by step using types and components.
Future work
currently, type traits are just placeholders that can be configured once everything is generic over types. Ideally we start with the Engine types (ethereum/optimism) but this needs more work on the existing components first (make them generic over EngineConfig).
Update
This currently only adds the node-builder, I want to do the replacement in a followup. because the PR is already gigantic
TODO

more ergonomics and helper types

Breaking changes
This phases out the NodeCommandConfig trait in it's existing form, instead all of its functionality will be moved into the NodeBuilder directly (hooks + helper functions for customizing payload builder for example)

general q: i can see that network, engine, payload builder, pool is all configured as components, but rpc seems separate, is this deliberate or will that config be unified later?

but rpc seems separate, is this deliberate or will that config be unified later?

RPC is based on the configured modules this can be extended with a hook.
I think we can/want to move away from this as well but for now it's significantly easier to rely on the RpcServerArgs

gotcha


Fix #3128: Avoid a binary incompatibility on JDK 7.

The method java.util.concurrent.ConcurrentHashMap.keySet() got a more precise result type in JDK 8. Since we build the distribution on JDK 8, the compiler links to the more precise signature, which then fails to link at run-time on a JDK 7. We work around the problem by an explicit upcast to java.util.Map, to force the compiler to resolve to the binary compatible bridge.

Amazing :)

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/4250/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5676/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/4252/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5678/
Test PASSed.

Jenkins, retest this please (PR was targeted at master)

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/4253/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5679/
Test FAILed.

Dear Jenkins, retest this please

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/4254/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5680/
Test PASSed.


feat(Group): constructors for minimal group axioms

I think it's worth spending a bit of time actually to get this right. Probably I should include npow, divetc. as anOptParam`. I'm not sure about this though. The difference should be invisible to most users right?

and not Group/ReducedAxioms or something

One argument for this is that if you also add CommGroup versions, we might have quite a lot of these, and Group/Defs is alraedy rather long.

I would prefer they go in a new file just so that this Algebra.Group.Defs doesn't get even longer. It's only a Defs file after all! :smile: I don't care much about the name of said file.

bors r+


ContactPicker dismisses my sheet

I'm displaying the ContactPicker inside a sheet and it all worked when it was contained in a form.
However, I struggled with the form, so I removed it.
Now when you chose a contact, my sheet gets dismissed.
Any ideas?
This code shows the issue that I am facing.
struct ContactPickerDemoView: View {
    @State var contact: CNContact?
    @State var showPicker = false
    @State var showingSheet = false

    var body: some View {
        Button(action: {
            self.showingSheet.toggle()
        }) {
            Text("Show Sheet")
        }
        .sheet(isPresented: $showingSheet) {
            ZStack {
                ContactPicker(
                    showPicker: $showPicker,
                    onSelectContact: {c in
                        self.contact = c})
                VStack{
                    Spacer()
                    Button(action: {
                        self.showPicker.toggle()
                    }) {
                        Text("Pick a contact")
                    }
                    Spacer()
                    Text("\(self.contact?.givenName ?? "")")
                    Spacer()
                }
            }
        }
    }
}

Yeah that's beyond my control unfortunately. From what I recall CNContactPickerViewController comes bundled with it's own sheet, that's maybe the reason why it dismissed your sheet.
You have a couple of options:

don't present CNContactPickerViewController from a sheet
implement your own contactPickerViewController

I was worried that you'd say that.
I'll do the first option.
Thank you for your library, it is helpful.


Kraken2_build step stalling

Hi there,
I'm continuing to troubleshoot the db-update process for a kraken2 database, and I've hit a wall at the kraken2_build step. The pipeline doesn't throw any errors; it just continues to run indefinitely (12+ hours without failure or completion). It seems similar to the problem described here: https://github.com/DerrickWood/kraken2/issues/428
So far, I've tried to implement the workaround mentioned in the comments of that issue I linked, where you add the --fast-build flag to the kraken2 call in the db-update snakefile, but it doesn't seem to have solved the issue. Any chance you've seen this before and/or have any thoughts on what might be causing it? I definitely have enough RAM. I'm using 28 cores with 16 Gb per core.
Thanks!

I've (thankfully) never experienced that issue. How many genomes are included in the build?

The database to be updated is the full GTDB_release207, and the sample TSV I'm trying to add includes ~4,000 genomes

A related question: if we instead passed the reads that were unclassified from GTDB into a second database (db-create with only the non-GTDB genomes), should that give similar results as a single database via the db-update workflow? There are methods for combining outputs for the same sample from different databases, though I imagine there could be downstream effects on Bracken estimates.

The downside of a 2-step classification approach versus a 1-step is that there is no direct "competition" during classification across the 2 steps. So, some reads could be falsely classified in the 1st step when they would actually be classified as something in the 2nd step if the 2 reference databases were combined.

Same problem here. I ran the kraken2 database building using 40 cores (7 GB each), and after 24 hours the process stalled at this point:
Creating sequence ID to taxonomy ID map (step 1)...
Sequence ID to taxonomy ID map already present, skipping map creation.
Estimating required capacity (step 2)...
Estimated hash table requirement:<PHONE_NUMBER>0 bytes
Capacity estimation complete. [37m21.355s]
Building database files (step 3)...
Taxonomy parsed and converted.
CHT created with 16 bits reserved for taxid.

@MixalisSn do you think that the stalling could be due to limited memory?

@nick-youngblut I thought the 120 GB were enough. Any way, I added the --fast-build flag, using the same resources, and the build was completed successfully.


[BEAM-2281][Sql] Use SqlFunctions.toBigDecimal not toString

Instead of using BigDecimal(object.toString()) to convert, use SqlFunctions.toBigDecimal which converts directly between numeric types. This speeds up the Nexmark Query 2 parDo by 2x.

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] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.

[X] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.

Tests were failing because precision information was being lost in the string conversion, so some tests were asserting the wrong values. Tests should pass now.

run java gradle precommit

retest this please


refactor: reduce code duplication between tonic and web-tonic

We should try to think how we can reduce code duplication between tonic and web tonic clients.

Originally posted by @bobbinth in https://github.com/0xPolygonMiden/miden-client/pull/449#discussion_r1710292165

This is mostly a duplicate of https://github.com/0xPolygonMiden/miden-client/issues/415


Add Base64Json type

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
Extend the Base64Str/Base64UrlStr types with a Base64Json type that works the same as the existing Json type but encodes the value as base64 encoded string.
The following model would generate the json schema below:
    class Model(BaseModel):
        a: Base64Json[List[int]]

{
  "type": "object",
  "properties": {
    "a": {
      "type": "string",
      "contentMediaType": "application/json",
      "contentEncoding": "base64",
      "contentSchema": {
        "type": "array",
        "items": {
          "type": "number"
        }
      }
    }
  }
}

Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[X] JSON Schema
[ ] Dataclasses
[ ] Model Config
[X] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

I am willing to make a PR for this feature if it would be accepted.

Hi @bschoenmaeckers,
Thanks for filing this issue 😄!
I think it might make more sense to instead create a Base64Json type that's annotated with a custom serializer. You can find an example here in the docs. Specifically, I think annotating with a PlainSerializer would work well. Would this fit your use case?
If we were to go go about adding this new type to Pydantic, I think that's how we'd do it.

Hi @bschoenmaeckers,
Any luck using Annotated and PlainSerializer for your use case?

@bschoenmaeckers
I'm going to go ahead and close this for now, but we're certainly happy to reopen if there's more support / demand.
At this point I think something like this probably belongs in user code, but we could also consider adding it to pydantic-extra-types.


Wrong typespec of pattern

When the following file is parsed, there is no ranges in the typespec of pattern:
module top;
   localparam int P [2] = '{11, 12};
endmodule

Here is uhdm:
slpp_all/surelog.uhdm: Restored design Pre-Elab:
design: (work@top)
|vpiName:work@top
|uhdmallModules:
\_module: work@top (work@top) pattern_type.sv:1:1: , endln:3:10, parent:work@top
  |vpiDefName:work@top
  |vpiFullName:work@top
  |vpiParameter:
  \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top
    |vpiName:P
<EMAIL_ADDRESS>    |vpiLocalParam:1
    |vpiSize:1
    |vpiRange:
    \_range: , line:2:22, endln:2:23<EMAIL_ADDRESS>      |vpiLeftRange:
      \_constant: , line:2:22, endln:2:23
        |vpiConstType:9
        |vpiDecompile:0
        |vpiSize:64
        |UINT:0
      |vpiRightRange:
      \_operation:
        |vpiOpType:11
        |vpiOperand:
        \_constant: , line:2:22, endln:2:23
          |vpiConstType:9
          |vpiDecompile:2
          |vpiSize:64
          |UINT:2
        |vpiOperand:
        \_constant:
          |vpiConstType:7
          |vpiSize:64
          |INT:1
    |vpiTypespec:
    \_int_typespec: (P), line:2:15, endln:2:18<EMAIL_ADDRESS>      |vpiName:P
  |vpiParamAssign:
  \_param_assign: , line:2:19, endln:2:36, parent:work@top
    |vpiRhs:
    \_operation: , line:2:27, endln:2:36
      |vpiOpType:75
      |vpiOperand:
      \_constant: , line:2:29, endln:2:31
        |vpiConstType:9
        |vpiDecompile:11
        |vpiSize:64
        |UINT:11
      |vpiOperand:
      \_constant: , line:2:33, endln:2:35
        |vpiConstType:9
        |vpiDecompile:12
        |vpiSize:64
        |UINT:12
    |vpiLhs:
    \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top
|uhdmtopModules:
\_module: work@top (work@top) pattern_type.sv:1:1: , endln:3:10
  |vpiDefName:work@top
  |vpiName:work@top
  |vpiParameter:
  \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top
    |vpiName:P
<EMAIL_ADDRESS>    |vpiLocalParam:1
    |vpiSize:1
    |vpiRange:
    \_range: , line:2:22, endln:2:23<EMAIL_ADDRESS>      |vpiLeftRange:
      \_constant: , line:2:22, endln:2:23
        |vpiConstType:9
        |vpiDecompile:0
        |vpiSize:64
        |UINT:0
      |vpiRightRange:
      \_operation:
        |vpiOpType:11
        |vpiOperand:
        \_constant: , line:2:22, endln:2:23
          |vpiConstType:9
          |vpiDecompile:2
          |vpiSize:64
          |UINT:2
        |vpiOperand:
        \_constant:
          |vpiConstType:7
          |vpiSize:64
          |INT:1
    |vpiTypespec:
    \_int_typespec: (P), line:2:15, endln:2:18<EMAIL_ADDRESS>      |vpiName:P
  |vpiParamAssign:
  \_param_assign: , line:2:19, endln:2:36, parent:work@top
    |vpiRhs:
    \_operation: , line:2:27, endln:2:36
      |vpiOpType:75
      |vpiOperand:
      \_constant: , line:2:29, endln:2:31
        |vpiConstType:9
        |vpiDecompile:11
        |vpiSize:64
        |UINT:11
      |vpiOperand:
      \_constant: , line:2:33, endln:2:35
        |vpiConstType:9
        |vpiDecompile:12
        |vpiSize:64
        |UINT:12
      |vpiTypespec:
      \_int_typespec: (P), line:2:15, endln:2:18                               <-------------
        |vpiName:P
    |vpiLhs:
    \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top

I think that the typespec should contain the information about the type of the whole pattern, not the type of one of the elements. Am I right?

Another problem is the name of the typespec. It is not type name, but parameter name and it gives problems in verilator. In other places we created workarounds, but in the case of patterns it would be more complicated. You said that you can remove it: https://github.com/chipsalliance/Surelog/issues/1708#issuecomment-908856994
Could you do it?

Fixed by #2106

There is still int typespec without ranges in that line.
And the ranges of parameter are now duplicated. There are both in the typespec and directly under parameter node.

Here is uhdm:
slpp_all/surelog.uhdm: Restored design Pre-Elab:
design: (work@top)
|vpiName:work@top
|uhdmallModules:
\_module: work@top (work@top) pattern_type.sv:1:1: , endln:3:10, parent:work@top
  |vpiDefName:work@top
  |vpiFullName:work@top
  |vpiParameter:
  \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top
    |vpiName:P
<EMAIL_ADDRESS>    |vpiLocalParam:1
    |vpiSize:1
    |vpiRange:
    \_range: , line:2:22, endln:2:23<EMAIL_ADDRESS>      |vpiLeftRange:
      \_constant: , line:2:22, endln:2:23
        |vpiConstType:9
        |vpiDecompile:0
        |vpiSize:64
        |UINT:0
      |vpiRightRange:
      \_operation:
        |vpiOpType:11
        |vpiOperand:
        \_constant: , line:2:22, endln:2:23
          |vpiConstType:9
          |vpiDecompile:2
          |vpiSize:64
          |UINT:2
        |vpiOperand:
        \_constant:
          |vpiConstType:7
          |vpiSize:64
          |INT:1
    |vpiTypespec:
    \_array_typespec:
      |vpiRange:
      \_range: , line:2:22, endln:2:23<EMAIL_ADDRESS>      |vpiElemTypespec:
      \_int_typespec: , line:2:15, endln:2:18<EMAIL_ADDRESS>  |vpiParamAssign:
  \_param_assign: , line:2:19, endln:2:36, parent:work@top
    |vpiRhs:
    \_operation: , line:2:27, endln:2:36
      |vpiOpType:75
      |vpiOperand:
      \_constant: , line:2:29, endln:2:31
        |vpiConstType:9
        |vpiDecompile:11
        |vpiSize:64
        |UINT:11
      |vpiOperand:
      \_constant: , line:2:33, endln:2:35
        |vpiConstType:9
        |vpiDecompile:12
        |vpiSize:64
        |UINT:12
    |vpiLhs:
    \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top
|uhdmtopModules:
\_module: work@top (work@top) pattern_type.sv:1:1: , endln:3:10
  |vpiDefName:work@top
  |vpiName:work@top
  |vpiParameter:
  \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top
    |vpiName:P
<EMAIL_ADDRESS>    |vpiLocalParam:1
    |vpiSize:1
    |vpiRange:
    \_range: , line:2:22, endln:2:23<EMAIL_ADDRESS>      |vpiLeftRange:
      \_constant: , line:2:22, endln:2:23
        |vpiConstType:9
        |vpiDecompile:0
        |vpiSize:64
        |UINT:0
      |vpiRightRange:
      \_operation:
        |vpiOpType:11
        |vpiOperand:
        \_constant: , line:2:22, endln:2:23
          |vpiConstType:9
          |vpiDecompile:2
          |vpiSize:64
          |UINT:2
        |vpiOperand:
        \_constant:
          |vpiConstType:7
          |vpiSize:64
          |INT:1
    |vpiTypespec:
    \_array_typespec<EMAIL_ADDRESS>      |vpiRange:
      \_range: , line:2:22, endln:2:23
        |vpiLeftRange:
        \_constant: , line:2:22, endln:2:23
          |vpiConstType:9
          |vpiDecompile:0
          |vpiSize:64
          |UINT:0
        |vpiRightRange:
        \_operation:
          |vpiOpType:11
          |vpiOperand:
          \_constant: , line:2:22, endln:2:23
            |vpiConstType:9
            |vpiDecompile:2
            |vpiSize:64
            |UINT:2
          |vpiOperand:
          \_constant:
            |vpiConstType:7
            |vpiSize:64
            |INT:1
      |vpiElemTypespec:
      \_int_typespec: , line:2:15, endln:2:18
  |vpiParamAssign:
  \_param_assign: , line:2:19, endln:2:36, parent:work@top
    |vpiRhs:
    \_operation: , line:2:27, endln:2:36
      |vpiOpType:75
      |vpiOperand:
      \_constant: , line:2:29, endln:2:31
        |vpiConstType:9
        |vpiDecompile:11
        |vpiSize:64
        |UINT:11
      |vpiOperand:
      \_constant: , line:2:33, endln:2:35
        |vpiConstType:9
        |vpiDecompile:12
        |vpiSize:64
        |UINT:12
      |vpiTypespec:
      \_int_typespec: , line:2:15, endln:2:18
    |vpiLhs:
    \_parameter: (work@top.P), line:2:19, endln:2:36, parent:work@top

It is correct, you need to turn on the -d vpi_ids option so you can see the ids:
|uhdmtopModules:
\_module: work@top (work@top), id:40 tests/ScratchPad.sv:1:1: , endln:3:10
  |vpiDefName:work@top
  |vpiName:work@top
  |vpiParameter:
  \_parameter: (work@top.P), id:41, line:2:19, endln:2:36, parent:work@top, parID:40
    |vpiName:P
<EMAIL_ADDRESS>    |vpiLocalParam:1
    |vpiSize:1
    |vpiRange:
    \_range: , id:42, line:2:22, endln:2:23<EMAIL_ADDRESS>parID:41
      |vpiLeftRange:
      \_constant: , id:43, line:2:22, endln:2:23, parID:42
        |vpiConstType:9
        |vpiDecompile:0
        |vpiSize:64
        |UINT:0
      |vpiRightRange:
      \_operation: , id:44, parID:42
        |vpiOpType:11
        |vpiOperand:
        \_constant: , id:45, line:2:22, endln:2:23, parID:44
          |vpiConstType:9
          |vpiDecompile:2
          |vpiSize:64
          |UINT:2
        |vpiOperand:
        \_constant: , id:46, parID:44
          |vpiConstType:7
          |vpiSize:64
          |INT:1
    |vpiTypespec:
    \_array_typespec: , id:47<EMAIL_ADDRESS>parID:41           <<<<< That is the typespec of the LHS (Parameter), of type array of ints, this is what the bug really was about, the typespec of the parameter missing the ranges and is now fixed.
      |vpiRange:
      \_range: , id:49, line:2:22, endln:2:23, parID:47
        |vpiLeftRange:
        \_constant: , id:50, line:2:22, endln:2:23, parID:49
          |vpiConstType:9
          |vpiDecompile:0
          |vpiSize:64
          |UINT:0
        |vpiRightRange:
        \_operation: , id:51, parID:49
          |vpiOpType:11
          |vpiOperand:
          \_constant: , id:52, line:2:22, endln:2:23, parID:51
            |vpiConstType:9
            |vpiDecompile:2
            |vpiSize:64
            |UINT:2
          |vpiOperand:
          \_constant: , id:53, parID:51
            |vpiConstType:7
            |vpiSize:64
            |INT:1
      |vpiElemTypespec:
      \_int_typespec: , id:48, line:2:15, endln:2:18, parID:47
  |vpiParamAssign:
  \_param_assign: , id:16, line:2:19, endln:2:36, parent:work@top, parID:40
    |vpiRhs:
    \_operation: , id:33, line:2:27, endln:2:36, parID:16
      |vpiOpType:75
      |vpiOperand:
      \_constant: , id:34, line:2:29, endln:2:31, parID:33
        |vpiConstType:9
        |vpiDecompile:11
        |vpiSize:64
        |UINT:11
      |vpiOperand:
      \_constant: , id:35, line:2:33, endln:2:35, parID:33
        |vpiConstType:9
        |vpiDecompile:12
        |vpiSize:64
        |UINT:12
      |vpiTypespec:
      \_int_typespec: , id:36, line:2:15, endln:2:18, parID:33   <<< That is the typespec of the RHS (The pattern assignment), it does only reflect the type of the data member (int), it is not adjusted for what it assigns to, it that important?
    |vpiLhs:
    \_parameter: (work@top.P), id:41, line:2:19, endln:2:36, parent:work@top, parID:40

"And the ranges of parameter are now duplicated. There are both in the typespec and directly under parameter node." and this what we exactly want.

Mmm let me reconsider...

Is the Yosys plugin confused by the fact the parameter typespec contains the range of the unpacked array and the parameter itself has the range of the unpacked array? But reading the Standard yesterday again, I think the typespec has to be complete and contain both unpacked an packed dimensions so the typespec alone should specify the data type of the parameter. I also keep the range of the unpacked array on the parameter, which is harmless and I think is still compliant with the standard (But to be verified by a 2nd opinion).

#2110 should fix this issue

"Is the Yosys plugin confused by the fact the parameter typespec contains the range of the unpacked array and the parameter itself has the range of the unpacked array?" - Verilator is confused. But if the ranges are now in the typespec, maybe we can omit handling the ranges in parameter. I will check.

It works.
I see that vpiTypespec of pattern now reflects the type of whole pattern, not only the data member. It was important, because if pattern was the value of type struct, the typespec was struct, not the field of the struct. But in case of array, the typespec reflected the type of the array element. Now in both cases it reflects the type of whole pattern.
Thank you.


Fixing indent rules for python formatter

Fixes https://github.com/microsoft/pxt-microbit/issues/2869
The indent logic in the python formatter assumes that the pasted text starts at the beginning of the line, which isn't always the case.

Figuring out how to write tests for those will pay off in the long run.


fix: fixed a problem reported on sentry io

This change should fix this.

I don't think the solution is valid, we should rather check why such test happened and either display error or fix a bug, but I'll keep it on my list to fix some day, good to not have the page fully breaking 👍


Connectivity plugin in windows desktop application

I'm using the plugin Connectivity in a Xamarin Forms App, I need to use in a Windows desktop application, honestly I did not understand why it should not be compatible, because it is compatible with windows store.
I can use it and how do
Can you help me ?

I haven't provided an implementation yet for anything windows desktop at this point. Are you building a WPF app? would need to call into the actual APIs for Windows to handle this.

No, it isn't a WPF app, but only a library.
I have done a own plugin for some function

Feel free to contribute and add in another platform if you would like :)


Gzip filter compresses content when Accept-Encoding header is not present in request

It looks like this is intended behavior as it is tested. However, the documentation states:

By default compression will be skipped when:
A request does NOT contain accept-encoding header.

https://github.com/envoyproxy/envoy/blob/a36fc3e8f2d64b86dbd2103f9143ac3515c16fba/source/common/http/filter/gzip_filter.cc#L193
https://github.com/envoyproxy/envoy/blob/a5550892f40cb8a3eb17477967ac27cbf63a61ba/test/common/http/filter/gzip_filter_test.cc#L195

cc @gsagula

It happened on our deployment environment. We expected no compression without the header, but envoy still compressed it.
I thinks it's a bug.
https://tools.ietf.org/html/rfc2616#page-103
The RFC also says that the proxy should use any encoding if no Accept-Encoding header specified:

If no Accept-Encoding field is present in a request, the server MAY
assume that the client will accept any content coding. In this case,
if "identity" is one of the available content-codings, then the
server SHOULD use the "identity" content-coding, unless it has
additional information that a different content-coding is meaningful
to the client.

@yudiandreanp @joshuarubin The filter should not compress the content when no Accept-Encoding is present. I'll work on the fix.
Thanks for reporting the issue.


ESTService.getCSRAttributes can't read response body

ESTService getCSRAttributes can't read response body. ESTException is returned with no body and message:
Stream closed before limit fully read, Read: 0 ContentLength: 55 HTTP Status Code: 404
getCACerts and simpleEnroll can do it w/o problems, the server behaves the same for all cases.

If you can provide a sample response we might be able to work out what's going on.

As far as I remember it was 404 response with 55 bytes of data as error message in JSON format.

So the issue was generating a response that the server couldn't read?

Opposite, server was responding with 404 and body. Give me an hour I'll bring my setup and try to reproduce the issue.

Here is what happens. Server responds with 404 and some body.
getCsrAttributes comes to the line
https://github.com/bcgit/bc-java/blob/master/pkix/src/main/java/org/bouncycastle/est/ESTService.java#L540
than continue to
https://github.com/bcgit/bc-java/blob/master/pkix/src/main/java/org/bouncycastle/est/ESTService.java#L566
which throws java.io.IOException: Stream closed before limit fully read, Read: 0 ContentLength: 45


Buff DataModel is probably broken

Deleting a conversion buff change always deletes the last change, not the one selected

It needs _id instead of id, which is probably primary problem.
target is no longer used, so it's excess data.
PF1 uses randomID(8) instead of randomID(16) for Change IDs but this is not actually bad.


ci: Set permissions for GitHub actions

Restrict the GitHub token permissions only to the required ones; this way,
even if the attackers will succeed in compromising your workflow,
they won’t be able to do much.

Included permissions for the action.
https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
Closes: #3072

Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

/retest ci/centos/<job-name>: retest the <job-name> after unrelated
failure (please report the failure too!)
/retest all: run this in case the CentOS CI failed to start/report any test
progress or results

As its a GitHub action change. merging it manually.


How do we name the output file?

I selected the "output to a single file" and gave it a file name in the sink, but when my job completes I get "part-00000-tid-1551909772045551232-225c89cf-b44a-4103-9cad-5f36b4bb55e1-49-c000.csv" instead of the file name I gave it. Any advice?

Please help with the link of document on which above document feedback request is created.
In case your query in not related to document content, open a new forum thread in MSDN forum or Stack Overflow as it could be better place to get help on your scenario. These forum community members could provide their expert guidance on your scenario based on their experience.


the review comment on a pr is always in pending status

Gitea version (or commit ref): Gitea version 1.12.1 built with GNU Make 4.1, go1.14.4 : bindata, sqlite, sqlite_unlock_notify
Git version: git version 2.20.1 (Apple Git-117)
Operating system: macos
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:

Description
the review comment on a pr is always in pending status. and after update the pr, these comments all disappeard.
bs. the try.gitea.io is accessed too slow . I did not try to reproduce in this site.
Screenshots

i am sure the database is running ok.

hello, I think you should submit your review after add comments.

This is a common problem -  I think this UI is poor (although it essentially replicates GHs behaviour).
@bigwhite you need to click the Review button in the top right and press one of approve, comment, request changes.

This is a common problem - I think this UI is poor (although it essentially replicates GHs behaviour).
@bigwhite you need to click the Review button in the top right and press one of approve, comment, request changes.

@zeripath got it , thank you


New package: Binutils_jll v2.38.0+3

Autogenerated JLL package registration

Registering JLL package Binutils_jll.jl
Repository: https://github.com/JuliaBinaryWrappers/Binutils_jll.jl
Version: v2.38.0+3
Commit: 2179028dfe60cce5f070f76af3a3d4447471f623

Look at all those build products...... https://github.com/JuliaBinaryWrappers/Binutils_jll.jl/releases/tag/Binutils-v2.38.0%2B3


DCES-429 Improve performance of contribution file updates

What
DCES-429 Improve performance of contribution file updates

Add specific increment of recordsReceived to Repository
Update Service to use Repository class instead of Entity
Simplify tests given simpler implementation

Checklist
Before you ask people to review this PR:

[x] Tests should be passing: ./gradlew test
[x] Github should not be reporting conflicts; you should have recently run git rebase main.
[x] Avoid mixing whitespace changes with code changes in the same commit. These make diffs harder to read and conflicts more likely.
[x] You should have looked at the diff against main and ensured that nothing unexpected is included in your changes.
[x] You should have checked that the commit messages say why the change was made.

Before this change
The update of recordsReceived needlessly queried and updated the XML LOB columns.
select f1_0.id,f1_0.accelerate,f1_0.agfs_complete,f1_0.agfs_cost,f1_0.agfs_vat,
    f1_0.cont_file_id,f1_0.date_calculated,f1_0.date_created,f1_0.date_modified,
    f1_0.date_replaced,f1_0.final_cost,f1_0.jud_apportion_percent,
    f1_0.lgfs_complete,f1_0.lgfs_cost,f1_0.lgfs_vat,f1_0.rep_id,f1_0.status,
    f1_0.user_created,f1_0.user_modified,f1_0.vat
from togdata.fdc_contributions f1_0
where f1_0.id=?                                         -- less than 1 second

select c1_0.id,c1_0.ack_xml_content,c1_0.date_created,c1_0.date_modified,
    c1_0.date_received,c1_0.date_sent,c1_0.file_name,c1_0.records_received,
    c1_0.records_sent,c1_0.user_created,c1_0.user_modified,c1_0.xml_content
from togdata.contribution_files c1_0
where c1_0.id=?                                         -- over 40 seconds

-- (non-JPA update of togdata.contribution_files using jdcbTemplate)
UPDATE TOGDATA.CONTRIBUTION_FILES
SET FILE_NAME=?, RECORDS_SENT=?, RECORDS_RECEIVED=?, USER_CREATED=?,
    DATE_CREATED=?, USER_MODIFIED=?, DATE_MODIFIED=?, DATE_SENT=?,
    DATE_RECEIVED=?, XML_CONTENT=XMLType(?)
WHERE ID=?                                              -- over 50 seconds

After this change
select f1_0.id,f1_0.accelerate,f1_0.agfs_complete,f1_0.agfs_cost,f1_0.agfs_vat,
    f1_0.cont_file_id,f1_0.date_calculated,f1_0.date_created,f1_0.date_modified,
    f1_0.date_replaced,f1_0.final_cost,f1_0.jud_apportion_percent,
    f1_0.lgfs_complete,f1_0.lgfs_cost,f1_0.lgfs_vat,f1_0.rep_id,f1_0.status,
    f1_0.user_created,f1_0.user_modified,f1_0.vat
from togdata.fdc_contributions f1_0
where f1_0.id=?                                         -- less than 1 second

update togdata.contribution_files c1_0
set c1_0.records_received=(coalesce(c1_0.records_received,0)+1),
    c1_0.date_received=current_date,
    c1_0.date_modified=current_date,
    c1_0.user_modified=?
where c1_0.id=?                                         -- less than 1 second


Export GitHub format

This looks very interesting. Is there a related issue that I can read up on to find more about the background/motivation behind the PR?

Related to https://github.blog/2022-02-22-github-advisory-database-now-open-to-community-contributions/?

@samj1912 only tangentially related to that, at this point.


docs: Fix arguments order in description of `defaultEqualityChec…

Fix arguments order in description of defaultEqualityCheck function.
Fix: https://github.com/reduxjs/reselect/issues/466

Thanks!


fix(whitelist): Adding more debugging

:tada: This PR is included in version 6.8.3 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


[Aura-Safe][Multisig Tx] Lỗi không thực hiện được transaction khi nhiều transaction chung một sequence

Description
Tạo nhiều transaction ở trạng thái confirm > khi thực hiện execute một transaction trong queue, các transaction còn lại bị lỗi
Environment

Browser: Chrome
Wallet: Keplr
Safe: evmos1rzkrw3z6xxf7zd2gfkv4n82dzr8hmyq3g00dhf
Environment: https://safe.serenity.aura.network/

testnet

Steps to reproduce

Go to https://safe.serenity.aura.network/
Connect wallet
Select a multisig safe with:
_ 2 owner
_ required signature = 1/2
Creat 2 transactions > show in queue
Execute 1 transaction in queue
Execute other transaction
See error

Expected result
only one transaction in queue at a time

Obtained result
Screenshots

Closed as will be analyzed and enhanced in https://github.com/aura-nw/multisig-api/issues/84


Notebook serializer does not contain cell execution summary info

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: Insiders
OS Version: Mac

Steps to Reproduce:

Create a serializer
Save a document with cells having an execution order
The execution order is not available in the cells

@jrieken @rebornix /cc


[Feature Request] Allow users to edit SQL

Allow users to edit SQL and run queries. We already have protections for non-read statements. Users should be able to iterate on/correct generated SQL queries manually.
This'll involve 2 changes:

front end: make SQL text area editable + add button to call backend to run query
back end: expose an endpoint to run SQL queries (function already implemented)

picked up by @noahvember


[New] Change viewpoint

Description
This PR implements Change viewpoint in Maps category.
URL to README: https://github.com/Esri/arcgis-maps-sdk-swift-samples/blob/des12437/Change-Viewpoint-Sample/Shared/Samples/Change viewpoint/README.md
Linked Issue(s)

swift/issues/3578

How To Test

Tap Geometry on the segmented control to change the map's viewpoint to one created with a geometry.
Tap Center & Scale to change the viewpoint to one set with a center and scale.
Tap Animate to view the map's current viewpoint zoomed in at a scale of 150% with a 5 second animation.

Screenshots

To Discuss

Segmented control has an option selected by default at start of Sample but this does not match the original Sample.
The images in the README render larger than expected.

I closed this PR since the branch became damaged after resolving merge conflicts in project.pbxproj and the project could no longer be opened. I added the sample to new branch and opened a new PR.


Prop Name Collision

Version: 0.3.0
Issue:
The block, element, modifiers prop names are too common that they cause collision with other typed component libraries, such as react-bootstrap. Therefore, we had suggested that we prefix the prop names a bit to reduce the chances of collision: bemBlock, bemElement, and bemModifiers
Code
Error when compiling code:
ERROR in [at-loader] ./node_modules/@types/react-bootstrap/lib/Button.d.ts:5:22
    TS2430: Interface 'ButtonProps' incorrectly extends interface 'HTMLProps<Button>'.
  Types of property 'block' are incompatible.
    Type 'boolean' is not assignable to type 'string'.

ERROR in [at-loader] ./node_modules/@types/react-bootstrap/lib/ButtonGroup.d.ts:5:22
    TS2430: Interface 'ButtonGroupProps' incorrectly extends interface 'HTMLProps<ButtonGroup>'.
  Types of property 'block' are incompatible.
    Type 'boolean' is not assignable to type 'string'.

ERROR in [at-loader] ./node_modules/@types/react-bootstrap/lib/ButtonToolbar.d.ts:5:22
    TS2430: Interface 'ButtonToolbarProps' incorrectly extends interface 'HTMLProps<ButtonToolbar>'.
  Types of property 'block' are incompatible.
    Type 'boolean' is not assignable to type 'string'.

Expected behavior:
No Typescript issues.
Actual behavior:
Error

This makes sense. The block, element and modifiers props were clearly a bit too generic for use with other 3rd-party packages. Will submit a PR to update these names.


Replace references to hardforks with specific EIPs

What was wrong?
Some docs strings in Berlin had reference to the hard fork name which was replaced by London in the London hard fork due to the new fork tool.
How was it fixed?
Corrected the docstrings to refer to the specific EIP instead.
Cute Animal Picture

Codecov Report
Base: 80.79% // Head: 82.53% // Increases project coverage by +1.74% :tada:

Coverage data is based on head (c48c2b0) compared to base (5e8a9c3).
Patch coverage: 98.13% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #611      +/-   ##
==========================================
+ Coverage   80.79%   82.53%   +1.74%
==========================================
  Files         370      407      +37
  Lines       20095    22342    +2247
==========================================
+ Hits        16236    18441    +2205
- Misses       3859     3901      +42

Flag
Coverage Δ

unittests
82.53% <98.13%> (+1.74%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/ethereum/berlin/eth_types.py
99.00% <ø> (ø)

src/ethereum/london/utils/hexadecimal.py
87.50% <87.50%> (ø)

src/ethereum/london/spec.py
90.45% <90.45%> (ø)

...ereum/london/vm/precompiled_contracts/ecrecover.py
92.85% <92.85%> (ø)

src/ethereum/london/utils/message.py
96.00% <96.00%> (ø)

src/ethereum/london/vm/gas.py
96.34% <96.34%> (ø)

src/ethereum/london/vm/interpreter.py
96.63% <96.63%> (ø)

src/ethereum/london/trie.py
97.79% <97.79%> (ø)

src/ethereum/london/eth_types.py
98.33% <98.33%> (ø)

src/ethereum/london/vm/instructions/system.py
99.52% <99.52%> (ø)

... and 28 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


THRIFT-5600: upgrade rust toolchain to 1.61 and edition 2021

upgrade rust toolchain to 1.50 to fix some compiling issues

closes #2627
closes https://github.com/apache/thrift/pull/2527

[x] Did you create an Apache Jira ticket?  (not required for trivial changes)
[x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
[x] Did you squash your changes to a single commit?  (not required, but preferred)
[x] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

before:

#2527
let's do this because it requires no gen code changes

this somehow erred but i don't think they are triggered by the change

could you kick it to get another CI run please?

I'm rerunning the build right now.

Suggest updating this to 1.61 as per conversation and also updating THRIFT_ROOT/rust_toolchain

i propose to merge this first - as the errors are Java related, which requires separate fixes. the master branch is now failing due to rust failures. this is really a seesaw situation.

@Jimexist could you possibly rebase and fix any conflicts?

@Jens-G and @allengeorge rebased now


Identify any loss of data when processing COVID samples through FHIR Engine

User Story:
As a developer, I want to know if COVID data samples used in the COVID pipeline result in data loss from using our current base schema in the FHIR engine, so I can document the missing data and create new issues to resolve them.
Description/Use Case
We need to use COVID data samples to find out if our configuration is missing anything.  Chances are we will see some data we are not converting and will need to add those fields to the respective configs.
Risks/Impacts/Considerations

There may be other missing fields in the future as we get more data, but we are going to just tackle those fields we find right now instead of tackling any possible field or permutation.
COVID sample data can be found in the repo in various places.

Dev Notes:

Refer to the HL7 mapping spreadsheets for how fields are being handled.

Acceptance Criteria

Use COVID samples available in our repo (this is non-PII data) to determine if there is any missing data we are not converting.
Document any missing data and create new issues as necessary to have the data in the final HL7 conversion.

We discussed this as a team and to validate this we want to use prime-router/src/testIntegration/resources/datatests/HL7_to_INTERNAL/CA-20211001-sully.hl7
Start out with sending this through the UP and comparing the data before and after, make sure it is all there. The suggestion was using transforms like the default sending transform paired with the Colorado receiver transform.
Then, run it through the COVID pipeline for Colorado and compare output. Likely this will expose the gap created by the covid-19 schema existing in the covid pipeline and the lack of an equivalent disease transform in the UP. This then gets into the question of whether or not disease transforms should be a thing which may need to be answered as part of this ticket.


Added Estonian locals

thanks.

Thanks for the PR.
Note that you had the wrong locale code 'ee' instead of 'et', and that you started from an old format. All fixed now.

@marcandre  what do you mean old format? isn't ee estonia according to ISO 3166-1 standard?


Private methods and protected methods hooks are not intercepted

Hi, I am trying to use promagent to collect some metrics, I was not able to intercept any private and protected methods with this library, could you please throw some light on this?

The current implementation instruments only public methods. From a quick look at the code it seems that it could be quite easy to support protected and private methods as well: Just remove the isPublic() check in io.promagent.internal.Promagent.matchAnyMethodIn() line 111. However, I didn't try it. I will get back to this as soon as I got the time to test it properly, but in the meantime you could just give it a try and comment out this line.

Thanks a lot it worked.
On Fri, Mar 9, 2018, 12:24 PM Fabian Stäber<EMAIL_ADDRESS>wrote:

The current implementation instruments only public methods. From a quick
look at the code it seems that it could be quite easy to support protected
and private methods as well: Just remove the isPublic() check in io.promagent.internal.Promagent.matchAnyMethodIn()
line 111
https://github.com/fstab/promagent/blob/a9e25911a70a17cd2c7ec6decf4702274a18a00c/promagent-framework/promagent-internal/src/main/java/io/promagent/internal/Promagent.java#L111.
However, I didn't try it. I will get back to this as soon as I got the time
to test it properly, but in the meantime you could just give it a try and
comment out this line.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/fstab/promagent/issues/3#issuecomment-371935462, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdQQQUfro65M7XOzHbqLIINkp0w6wbqks5tcuUCgaJpZM4Si-1_
.

Great. Removed the line from the code.


Images hiding in Telegram

Describe the bug
Sometimes in Telegram, images in a conversation suddenly disappear.  The space for them shows up but the images don't. Reloading the service fixes it but after another unknown amount of time they disappear again
To Reproduce
Use Telegram until images disappear
Expected behavior
Images in conversations stay visible.
Desktop (please complete the following information):

OS: MacOS 10.14.6 - Happens on 10.15 too
Browser Chrome 79

Also happened when I was using Franz

I can't reproduce this bug locally so I can't investigate for myself.
Can you please try ans see if Telegram's service.css may be at fault? Open the file at ~/Library/Application Support/Ferdi/recipes/telegram/service.css and remove its contents (do not delete the file, only its contents as deleting the file can cause issues).

I reproduced the bug as well, although refreshing does not always work and it happens with images/videos/stickers, I believe it's just that the images/videos take a long time to download. I use a VPN.

This happens to me as well - and yesterday I confirmed it happens to another friend of mine who uses Ferdi as per my recommendation.
Images in Telegram do not show. For us, at least, no images whatsoever.
I found this bug and decided to comment on it instead of opening up a new bug, but I can confirm that 3 separate installations act the same.

having the same issue, restarting ferdi is a temporary fix until it happens again...

Same, no images show up, but space is occupied and empty (white). Reloading the service Telegram by rightklick on symbol -> Reload fixes this. Running:
Ubuntu 20.04
Ferdi 5.5.0 (64x)
Electron 8.2.3
Node.js v12.13.0

This issue has been automatically marked as stale because it has not had recent activity. Please check if this issue is still relevant and please close it if it's not. This will make sure that our open issues are actually of use and reduce the list of obsolete issues. Thank you for your contributions.

Still relevant I afraid

@rctneil @sebastien1234 @PashaKagan @rafaelmaeuer @shukon - could you please try with the latest nightlies? http://github.com/getferdi/nightlies/releases - I think this issue is fixed.

I had this happening to me too with the telegram recipe, but never with the telegram-react recipe, so in case the latest nightly doesnt fix it, switchign

Yes - I have also moved from the telegram recipe to the telegram-react recipe.
Also - fyi, we released a new beta yesterday.
Closing since there's no confirmation.


some confusion about the ray direction?

thanks for your awesome work!
but i have some confusion about the code.
In the plane_extractor.cpp
void PlaneExtractor::extend_planes_and_cast_plane_points(double extend_rpe_ratio) {
    std::unique_lock planes_lock(planes_mutex);
    std::vector<Plane *> candidate_planes;
    std::vector<vector<3>> candidate_plane_points;
    for (size_t i = 0; i < map->track_num(); ++i) {
        Track *track = map->get_track(i);
        if (!track->flag(TrackFlag::TF_VALID)) continue; // it seems better to skip these invalid tracks
        vector<3> point = track->get_landmark_point();
        const auto &[frame_ref, keypoint_index_ref] = track->first_keypoint();
        const auto camera_ref_pose = frame_ref->get_pose(frame_ref->camera);
        double rpe_before_project = compute_reprojection_error(map, track, point);
        vector<3> direction = camera_ref_pose.q * frame_ref->get_keypoint(keypoint_index_ref).homogeneous();  // may be wrong?

the direction compute by R * [u,v,1], but it should be R*K^ * [u,v,1]?
K^ is the inverse of the intrinsic?

Hi, the result of Frame::get_keypoint(...) is an Eigen::Vector2d variable which lies in the camera's normalized plane (z = 1).
https://github.com/zju3dv/PVIO/blob/a6acc8a2d26d2c8eca5e16d2e66e450a72b2dd49/pvio/src/pvio/map/frame.h#L62-L64
This step is done during keypoint detection,
https://github.com/zju3dv/PVIO/blob/a6acc8a2d26d2c8eca5e16d2e66e450a72b2dd49/pvio/src/pvio/map/frame.cpp#L72-L87
using remove_k to apply the K^{-1} left multiplication you mentioned above.
https://github.com/zju3dv/PVIO/blob/a6acc8a2d26d2c8eca5e16d2e66e450a72b2dd49/pvio/src/pvio/geometry/stereo.h#L29-L31
So, to wrap up, frame_ref->get_keypoint(keypoint_index_ref).homogeneous() is of type Eigen::Vector3d, meaning the 3d coordinate of this keypoint in the corresponding camera's normalized plane, which does not need another K^{-1} left multiplication.


Convert from schema to function

It would be nice to have the ability to take a schema (e.g. returned by OpenAI) and return a function that can be called that executes the function with the appropriate parameters.
For example:
import tool2schema
import tools  # Module containing all tools

f = tool2schema.ParseSchema(tools, schema)
f()  # Call the function

Would be nice if it did automatic validation to check if the schema conforms with the function definition (perhaps using Pydantic?). It should use the function name to match the schema to the appropriate function.
Given we are supporting OpenAI only at the moment, the schema variable is a subset of the Chat Completion object. That is:
schema = {
  "function": {
    "name": "my_function",
    "arguments": # JSON string of arguments
  }
}

I suppose this is schema2tool and we've already outgrown our tool2schema name!

Thoughts @lorenzocelli?

Yep looks like a useful tool!
In this example:
f = tool2schema.ParseSchema(tools, schema)
f()  # Call the function

Could f be a wrapper to one of the decorated functions, without passing any tools?

How would not passing tools work? I added that because you would need to get the function somehow.
schema being the JSON object that is returned by the OpenAI API so has no reference to things like FunctionSchema.

Let's try it without a wrapper for now (keeps the one liner shorter).
The wrapper could potentially be useful later on, so let's keep that in mind!


Discrepancy in mass calculation from mesh

I'm seeing a significant difference in mass calculation from meshes in two different MuJoCo versions. Here is a minimal example:
from dm_control import mjcf

xml = """
<mujoco>
    <asset>
        <mesh name="thorax" file="thorax_body.msh"/>
    </asset>
    <worldbody>
        <body name="thorax">
           <geom name="thorax" type="mesh" mesh="thorax" density="0.478"/>
        </body>
    </worldbody>
</mujoco>
"""

physics = mjcf.Physics.from_xml_string(xml)
mass = physics.named.model.body_mass['thorax']

print(mass)
# Prints 0.20764519675374468 in mujoco 2.3.1
# Prints 0.22578387429620797 in mujoco 3.1.2

This particular thorax_body.msh mesh can be found here, but the issue is not specific to this mesh and probably any mesh would do.
Any ideas would be very helpful!

This is caused by the change
https://github.com/google-deepmind/mujoco/commit/ffca553f645b5c2fcfdfffc7eb3f462b271f5368
The old computation inferred the volume of the object from the inertia box whereas we now use the actual volume for computing the mass. Apologies if this was not documented in the changelog.

Thank you! This is good to know.


Karma can be fraudulently earned by logging into channels with a different name

Logging into channels with a different user name should not allow a user to award karma to themselves. This is currently possible in some channels. The appropriate response to awarding yourself karma is: https://github.com/oldterns/VileBot/blob/e9d0810a107c1278df56440c60ac5a96e186339a/vilebot/src/main/java/com/oldterns/vilebot/handlers/user/Karma.java#L109
This may also be related to #50
and could also incorporate #63 for bonus karma
/cc @salmanfs815 @dobsonke

If it’s possible to check the address of the user and not just the username, there could be a check for it, so if a user with the same address is trying to ++ themselves it would default to insult. However, if two people were hijacking it and ++-ing each other that check wouldn’t be sufficient. I haven’t looked into it too deeply but hopefully @salmanfs815 and @dobsonke can figure something out 😊

It is possible to check the address of the user using the WHO command [0]. Any IRC clients running on the same machine (even with unrelated nicks) will have the same address.
[0] https://tools.ietf.org/html/rfc2812#section-3.6.1

The issue is that you can ++ someone who isn't present (which is an important feature). If I were to try and game the system, I would just /nick myself to something else and ++ myself, then /nick back.

@amisevsk that is an important consideration that doesn't seem to have an easy solution (I'm sure it's not completely impossible to stop--though maybe impractical). One could create a registry of users with ++ ability for example, and Vilebot would have to check if the user ++-ing is in the registered user list which is managed by the maintainer. I'm not sure if this is the way we want to go though.
I think ensuring a user is unable to ++ another user with the same address should be relatively simple to implement and would stop some bad behaviour--though certainly not all. Another thing is to implement #63 which could limit the number of times someone can ++ the same person (or repeat the same phrase) in a specified period of time. This would at least reduce the ability for a user to ++ themselves without any breaks all day.

Conventionally, abusing the karma system like this is prevented by social pressure. You can only give or subtract karma in the main channels where VileBot idles, which would also have people in them, who can see in their chat logs what was happening.
There's no perfect solution without mandatory authentication on the IRC server.
Also, regarding the ability to modify the karma of someone who isn't there: That's a desirable feature, and the database contains "nouns" generally, not just usernames. So someone could do java++ for example, and that would be tracked.

@ASzc there are now several game channels where the ++ function (was #80) enabled which may not always have been the case.
@salmanfs815 @dobsonke, you could still work on #50, #63 and making sure a user with the same address can't ++ themselves to keep the karma you gave yourselves, but as @ASzc says, collective shaming will probably do a lot of the work here.

We can use Karmalytics to determine if someone has been spamming ++'s/--'s, and if so, revert those transactions and remove X karma from the user who been spamming.


Release 0.0.3

Codecov Report

Merging #3 (b692460) into master (a88bcb3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #3   +/-   ##
=======================================
  Coverage   89.55%   89.55%
=======================================
  Files           5        5
  Lines         268      268
=======================================
  Hits          240      240
  Misses         28       28

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 a88bcb3...b692460. Read the comment docs.


ROOT 6.18.04

Checklist

[x] Used a fork of the feedstock to propose changes
Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

requirements: host: clangdev=5.0.0 must contain a space between the name and the pin, i.e. clangdev =5.0.0
requirements: host: llvmdev==5 must contain a space between the name and the pin, i.e. llvmdev ==5

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Looks like the 6.18.02 patches need to be renamed 6.20.00, they were not backported.

@conda-forge-admin, please rerender


Improve exec on JRuby

Unfortunately I can't get testsuite running locally, hope that travis will tell that changes are OK.
Fixes https://github.com/bundler/bundler/issues/4586.
I don't really know if test should be added for the last commit, please advise.

Ouch, JRuby is not tested on travis :/.
Anyway, manual testing of exec on JRuby works fine locally and changes are not too invasive, so hope that's ok.

@homu r+

:pushpin: Commit 550ba8a has been approved by segiddins

:hourglass: Testing commit 550ba8a with merge 5515464...

:sunny: Test successful - status


Migrate docker images to ghcr

Contributes to #197

Codecov Report

Merging #199 (222be70) into main (1f6d383) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #199   +/-   ##
=======================================
  Coverage   78.25%   78.25%
=======================================
  Files          16       16
  Lines        1366     1366
=======================================
  Hits         1069     1069
  Misses        240      240
  Partials       57       57

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 1f6d383...222be70. Read the comment docs.


Artifact sizes and bootstrap in Cloud native environments.

One huge aspect we face in a project is, that Java does perform pretty bad on highly dynamic infrastructure, as it's startup time is "horrible" for an interpreted language.
Using services like google cloud run or cloud functions with dynamic scaling down to zero have highly impact on first requests per instance.
Especially when using JVM in default configuration with frameworks like Spring/Graal/Micronaut, as they often have some beans which are initialized lazily at first invocation.

makes sense :( probably that is why they added rust support: no initialization penalty.
How do cloud functions perform in Go?

I have little experience on golang and no experience in running golang based application at all nor in cloud functions.
I can imagine it should be at a similar class of rust, being natively compiled.
Rust is not supported in Cloud Functions, you gotta go for the Cloud Run solution and containerize your artifact.

AWS Lambdas in Rust!! https://docs.aws.amazon.com/sdk-for-rust/latest/dg/lambda.html


Indeterminate Progress Bar

I don't know if you take feature requests here, but I think an indeterminate progress bar would be great. Something along the lines of what Android does (http://i.stack.imgur.com/m1aGNm.png - the blue lines at the top are animated to move left to right in an infinite loop).

Yes, this is a interesting feature that I will be looking into. If anyone have any ideas or want to try and implement it, let me know.


Can't connect to Bitcoin Core: Server returned HTTP response code: 403 for URL

Team,
I'm trying to connect Sparrow to my Bitcoin Core 0.25 full node. I tried using the .cookie file, and also the rpcuser and rpcpassword. I have rpcauth enabled too.
I always get
Could not connect:
Server returned HTTP response code: 403 for URL: http://<IP_ADDRESS>:18332/wallet/cormorant

18332 is the correct port (not using 8332 directly)
In bitcoin.conf, I have the security set like this:
Server=1
rpcuser=user
rpcpassword=password
rpcauth=user:4e98892384899f9a.....

What else can I try?

The HTTP response 403 means a client authentication error.
I suspect you just need to delete the rpcauth line.

I fixed it!
I had the connecting PC excluded from the rpcallowip range.
Thanks for making me think @craigraw


Select cell functions

There is no ticket associated with this PR.
Fixed vertical scroll max calculation (was not displaying final rows).
This in turn fixed selectFinalCell and selectToFinalCell which failed because final row was not displayable.
Also refined calculation of column with for handle column which was too narrow to accommodate row numbers when bolded (row selected) and was showing elipsis.

This brings up questions I have about this. Since subgrids are arbitrary is this a matter of just customizing the scroll bar dom element size

The scrollbars can be custom-positioned.

@Dwaynekj Ready for final review on this. Let's get this sucker merged!

Manual testing looks good

@Dwaynekj Did you notice the new "Link styles" dashboard control?


chore,refactor(egen) : Added clean up code for deletion of model endpoint and local files, refactored code according to template guidelines, performed linter test

This PR includes the following updates:

Adds Colab Enterprise link and other structural changes from the new template.
Changes REGION variable name to LOCATION
Changes BQ_REGION variable name to BQ_LOCATION
Adds clean up code for model endpoint deletion and local files deletion
Removes IS_TESTING from the cleaning up section.
Adds comments for cells needed.
Removes the usage of future tense.

REQUIRED: Fill out the below checklists or remove if irrelevant

If you are opening a PR for Official Notebooks under the notebooks/official folder, follow this mandatory checklist:

[x] Use the notebook template as a starting point.
[x] Follow the style and grammar rules outlined in the above notebook template.
[x] Verify the notebook runs successfully in Colab since the automated tests cannot guarantee this even when it passes.
[x] Passes all the required automated checks. You can locally test for formatting and linting with these instructions.
[ ] You have consulted with a tech writer to see if tech writer review is necessary. If so, the notebook has been reviewed by a tech writer, and they have approved it.
[ ] This notebook has been added to the CODEOWNERS file under the Official Notebooks section, pointing to the author or the author's team.
[x] The Jupyter notebook cleans up any artifacts it has created (datasets, ML models, endpoints, etc) so as not to eat up unnecessary resources.

/gcbrun

/gcbrun


feat(calendar): additional features

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our
guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Which package are you modifying?

[ ] accordion
[ ] alert
[ ] alert-dialog
[ ] aspect-ratio
[ ] avatar
[ ] badge
[ ] button
[x] calendar
[ ] card
[ ] checkbox
[ ] collapsible
[ ] combobox
[ ] command
[ ] context-menu
[ ] data-table
[ ] date-picker
[ ] dialog
[ ] dropdown-menu
[ ] hover-card
[ ] icon
[ ] input
[ ] label
[ ] menubar
[ ] navigation-menu
[ ] pagination
[ ] popover
[ ] progress
[ ] radio-group
[ ] scroll-area
[ ] select
[ ] separator
[ ] sheet
[ ] skeleton
[ ] slider
[ ] sonner
[ ] spinner
[ ] switch
[ ] table
[ ] tabs
[ ] textarea
[ ] toast
[ ] toggle
[ ] tooltip
[ ] typography

What is the current behavior?

Closes #
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Opening this draft PR as promised. I know #401 is open to close #111 and honestly that pr is super clean and definitely in a more complete state than this. I would be open to refactoring this on top of that for sure I think we could maybe consider adding material like calendar navigation as separate issue/feature.
https://github.com/user-attachments/assets/ed194833-b2c2-432d-974b-549c11154458


Suggestion: Color Code options for active/depleted.

A color code field for the two colors to use would be useful for us colorblind. I still use this and the pickaxe icon is plenty of notification, but color options would be nice. Thank you for this plugin.

Done.


Metadata Field Not Included In POST Event Response

I'm creating a new TGEvent and I'm setting the metadata value. I see that it is serialized correctly but it is not included in the response.
TGEvent event = new TGEvent()
    .setType("like")
    .setLanguage("en")
    .setLocation("berlin")
    .setVisibility(TGEvent.TGEventVisibility.Global)
    .setMetadata("some metadata");

Request:
{
	"language": "en",
	"location": "berlin",
	"metadata": "Testing -<PHONE_NUMBER>328",
	"type": "like",
	"user_id":<PHONE_NUMBER>3445665,
	"visibility": 40
}

Response:
{
	"id_string": "18539782648893028",
	"tg_object_id": "0",
	"user_id_string": "18291535703445665",
	"id":<PHONE_NUMBER>8893028,
	"user_id":<PHONE_NUMBER>3445665,
	"type": "like",
	"language": "en",
	"location": "berlin",
	"visibility": 40,
	"object": null,
	"object_id": 0,
	"owned": false,
	"created_at": "2016-01-06T15:43:11.592759216Z",
	"updated_at": "2016-01-06T15:43:11.592759216Z",
	"enabled": true
}

This can be reproduced with the Tapglude Android example app.
If I issue a request to create a new event via curl, the metadata field is included in the response correctly.

Aright. I figured out what the problem is. It's a bug in API version 0.4.
See logs below. Same request with same payload. 0.3 response has metadata. 0.4 response has no metadata.
@onurakpolat Is this a bug or feature? If bug, when you think it could be fixed? Thanks!
curl https://api.tapglue.com/0.3/me/events \
>     -u 2529e450f4765ca138554011cb5c6559:SWFOLEtlTWw/bCprQi1+bFlvVTg= \
>     -H 'Accept: application/json' \
>     -H "User-Agent: Tapglue Test UA" \
>     -H "Content-Type: application/json" \
>     -d "{\"type\":\"bookmark\",\"object\":{\"id\":\"picture_123\",\"type\":\"picture\",\"display_names\":{\"en\":\"Picture 1\",\"de\":\"Bild 1\"}},\"metadata\":{\"category\":\"landscape\"},\"visibility\":40}"

{"id_string":"20039054296878887","user_id_string":"18535644582121605","id":20039054296878887,"user_id":18535644582121605,"type":"bookmark","visibility":40,"object":{"id":"picture_123","type":"picture","display_names":{"de":"Bild 1","en":"Picture 1"}},"metadata":{"category":"landscape"},"created_at":"2016-01-16T23:57:07.132006109Z","updated_at":"2016-01-16T23:57:07.132006109Z","enabled":true}

curl https://api.tapglue.com/0.4/me/events \
>     -u 2529e450f4765ca138554011cb5c6559:SWFOLEtlTWw/bCprQi1+bFlvVTg= \
>     -H 'Accept: application/json' \
>     -H "User-Agent: Tapglue Test UA" \
>     -H "Content-Type: application/json" \
>     -d "{\"type\":\"bookmark\",\"object\":{\"id\":\"picture_123\",\"type\":\"picture\",\"display_names\":{\"en\":\"Picture 1\",\"de\":\"Bild 1\"}},\"metadata\":{\"category\":\"landscape\"},\"visibility\":40}"

{"id_string":"20039078825168679","tg_object_id":"0","user_id_string":"18535644582121605","id":20039078825168679,"user_id":18535644582121605,"type":"bookmark","visibility":40,"object":{"id":"picture_123","type":"picture","display_names":{"de":"Bild 1","en":"Picture 1"}},"object_id":0,"owned":false,"created_at":"2016-01-16T23:57:21.751568327Z","updated_at":"2016-01-16T23:57:21.751568327Z","enabled":true}

@thorbenprimke thanks for the details. We'll investigate this asap, in any case metadata should be there if you send it.

I've updated the comments above. @thorbenprimke please make sure next time you don't leak tokens ;) Thank you for the detailed investigation.

@xla can you please have a look on this https://github.com/tapglue/android_sdk/issues/3#issuecomment-172277940 ? Thanks.

@dlsniper On it. @thorbenprimke Thanks for the investigation.

@thorbenprimke the fix is out. Metadata should be available now!


Ability to boot from a block device

Nova has the ability to boot from a block device, it would be nice if we could support this in nova-lxd as well.

I'm assuming you mean a formatted block device?


add compatibility with the glam library

This adds some basic compatibility with the glam library.
It implements FloatPointCompatible<f32> for glam::Vec2, and FloatPointCompatible<f64> for glam::DVec2, as well as implementing From<> for back and forth between the types.
For IntPoint, it implements From and back.
I tried to follow the conventions used by this project, let me know if you need any changes.

Hi, gordlea!
Thank you for the contribution! However, I’ve decided not to merge this pull request for two reasons:

Adding glam as a dependency can cause version conflicts for users relying on a different version.
I want to keep the library clean and lightweight, allowing users to implement FloatPointCompatible for their types as needed.

I encourage creating a separate crate for glam integration if desired. Thank you for understanding!

That's disappointing. The problem is, to implement a trait, like FloatPointCompatible, you need to either have defined trait or the struct that is implementing the trait in your crate. So basically, if a developer doesn't control either crate, they can't really use the trait.
Is there another way do this?
Also, this should work even if you set the glam version to "*", would that change your mind at all?

After some research I understand that it will be the most simple and comfortable way to add support of external types.
Please accept my apologies.
But let it be a little cleaner in case we need to add some more libraries.
need move all external types to a new module:
src/
|- lib.rs
|- integration/
|- |-mod.rs
|- |-glam.rs
lib.rs:
#[cfg(any(feature = "glam"))]
pub mod integration;
glam.rs:
#[cfg(feature = "glam")]
pub mod glam;
for glam dependencies version it's better to use * as you mentioned

That's great news, I've made the requested changes. Thanks for being open to discussion 👍

I just realized that with this change, since i_overlay re-exports iFloat, we might need to add a glam feature to that which wil activate this one. Once this is merged I can open a PR for that also if you'd like.

And looks like it must be done for both as for iOverlay and as for iTraingle


z400+ switching bug

Currently, when you switch to z400+ it adjusts a couple of the advanced options.
When you then switch back to any of the other presets, it leaves those advanced options in place, which obviously produces completely different perk suggestions.
Obviously you don't want the advanced settings to be reset every time you change the presets dropdown, but those specific settings the z400+ impacts could be reset when you switch out of z400+, on the condition that they also haven't been changed...
Edit: just realised this had already been reported, and after testing those advanced settings aren't actually what breaks the suggestions...

This is a duplicate of #7, that I just fixed.
However, it sounds like you had another issue as well. What do you mean by breaking the suggestions? Did Perky recommend a particularly bad perk distribution?

The advanced settings do now reset themselves properly, but for some reason the suggestions don't return to what they were before.
For example, with my current save export, on the broken planet preset it is recommending 20 coordinated.  If I switch to z400+ then is recommends a setup with 22 coordinated.
Now when I switch back to broken planet, it is still recommending a setup with 22 coordinated, although different from the z400+ suggestion.

Thanks for the details! This is now fixed as well.


Add @k-knosala to contributers

I would like to contribute to the ontology and am therefore adding my ID to the contributors list.

Welcome and thank you for contributing!

Thank you!


[#6156] Polishing

Codecov Report

Merging #6286 into master will increase coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #6286      +/-   ##
==========================================
+ Coverage   39.57%   39.58%   +<.01%
==========================================
  Files        3061     3061
  Lines       91411    91415       +4
  Branches    11844    11845       +1
==========================================
+ Hits        36179    36186       +7
- Misses      52247    52248       +1
+ Partials     2985     2981       -4

Impacted Files
Coverage Δ

...m/navercorp/pinpoint/bootstrap/PropertyLoader.java
0% <0%> (ø)
:arrow_up:

.../navercorp/pinpoint/bootstrap/PinpointStarter.java
0% <0%> (ø)
:arrow_up:

...rp/pinpoint/bootstrap/agentdir/AgentDirectory.java
38.63% <0%> (ø)
:arrow_up:

...p/pinpoint/rpc/stream/StreamChannelRepository.java
75% <0%> (-10%)
:arrow_down:

...point/rpc/client/DefaultPinpointClientHandler.java
72.4% <0%> (+0.32%)
:arrow_up:

...orp/pinpoint/rpc/server/DefaultPinpointServer.java
79.92% <0%> (+0.7%)
:arrow_up:

...pinpoint/profiler/monitor/DeadlockMonitorTask.java
19.76% <0%> (+1.16%)
:arrow_up:

...cluster/zookeeper/ZookeeperClusterDataManager.java
54.83% <0%> (+1.93%)
:arrow_up:

...om/navercorp/pinpoint/rpc/codec/PacketDecoder.java
59.57% <0%> (+2.12%)
:arrow_up:

Continue to review full report at Codecov.

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


setup: Merge multiple setup-apt-repo scripts into one.

This moves the .asc files into subdirectories, and writes out the
according .list files into them.  For the special-case of the
PGroonga signing key, we source an additional file within the
directory.
This simplifies the process for adding another .list file.
Testing plan: Existing installer tests.  Ran ./scripts/lib/setup-apt-repo repeatedly to ensure it was a no-op with no changes, and ran with .asc changes; did so with and without --list ksplice

Merged, thanks @alexmv!


fix machine delete issue

https://github.com/rancher/rancher/issues/11226

this raised a bug which cluster is already deleted but remove will return a 404 not found error which prevent itself from being deleted.