Domain exists: probably not, or blocked by the proxy - pihole

Same as  #858,
./dnscrypt-proxy -resolve google.com
Resolving [google.com]

Domain exists:  probably not, or blocked by the proxy
Canonical name: -
IP addresses:   -
TXT records:    -

Running it in conjunction with pihole on an rpi3. Installed using: https://github.com/pi-hole/pi-hole/wiki/DNSCrypt-2.0 as a guide

server_names = ['scaleway-fr', 'google', 'yandex', 'cloudflare']

## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6.
## Note: When using systemd socket activation, choose an empty set (i.e. [] ).

listen_addresses = ['<IP_ADDRESS>:5353', '[::1]:5353']

sudo ./dnscrypt-proxy -list
[2019-06-17 18:34:05] [NOTICE] Network connectivity detected
[2019-06-17 18:34:05] [NOTICE] Source [public-resolvers.md] loaded
cloudflare
scaleway-fr
google
yandex

sudo ./dnscrypt-proxy -check
[2019-06-17 18:33:55] [NOTICE] Network connectivity detected
[2019-06-17 18:33:55] [NOTICE] Source [public-resolvers.md] loaded
[2019-06-17 18:33:55] [NOTICE] Configuration successfully checked

If I enable dnscrypt as the upstream resolver, I get the above error, if I enable pihole w/ cloudfare as the upstream, I get the following:
./dnscrypt-proxy -resolve google.com
Resolving [google.com]

Domain exists:  yes, 4 name servers found
Canonical name: google.com.
IP addresses:   <IP_ADDRESS>, 2a00:1450:4009:811::200e
TXT records:    v=spf1 include:_spf.google.com ~all docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95 globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8=
Resolver IP:    <IP_ADDRESS>

Please let me know if there are any other config listings I need to post! Thanks!

With 2.0.25, don't get this kind of report, [Notice]s are missing.
./dnscrypt-proxy -list
ads-securedns-ipv6-doh

Correct, only one 'server_names',' IP4/IP6_serverS' true.
./dnscrypt-proxy -check

Returns nothing, just get a new prompt.
./dnscrypt-proxy -resolve google.com
-cut-
Resolver IP:    <IP_ADDRESS> (dns2.securedns.eu.)

Is similar; ok.

Could it be this setting?
HTTP/HTTPS proxy only for DoH servers
http_proxy = "http://<IP_ADDRESS>:8888"

Hmmm, attempted to uncomment that, and restart the service, but still no go.
http://paste.debian.net/1088224/
I'm sure this is an ID10T issue on my end

I saw on the doc:

you have to change, port, your port is 5353 but not these 2 in your .toml, specially the second one, I don't know if it's required too.

fallback_resolver = '<IP_ADDRESS>:53'
netprobe_address = "<IP_ADDRESS>:53"

the doc, he sets dnssec to true, I don't know if there is a reason, or just an example for the explanations.

require_dnssec = false

Try to change the 2x53 into 2x5353

But <IP_ADDRESS> is for quadnine, not for internal, so it wouldn't be listening on 5353 at their end.
Address and port to try initializing a connection to, just to check
if the network is up. It can be any address and any port, even if
there is nothing answering these on the other side. Just don't use
a local address, as the goal is to check for Internet connectivity.
Also just checked to see if it was listening and it certainly is:
dnscrypt- 8117     user    5u  IPv4 5039668      0t0  TCP <IP_ADDRESS>:54 (LISTEN)
dnscrypt- 8117     user    7u  IPv6 5039670      0t0  TCP [::1]:54 (LISTEN)

OK, this has been resolved.
It seems I was running both the installed service and the /opt/ service.
I stopped the opt service, restarted the installed service, and all seems to be working as expected.


Add willSet / didSet support to Observable (kind of)

This way a model can use willSet / didSet on it's own Observables:
    let someValue = Observable<Int?>(nil)
        .willSet{
            value, newValue in
            print("CURRENT: \(value) -> NEW: \(newValue)")
        }
        .didSet{
            oldValue, value in
            print("OLD: \(oldValue) -> CURRENT: \(value)")
        }

Hmm, don't know if this is the best idea ever actually :)
I miss the willSet/didSet when i made something Observable, and this solution actually works ok.
However, with this construction it is not possible to refer to self in the willSet / didSet.
The 'solution' is to set the willSet / didSet later (in init for example).
That is not really nice.
And it looks like it might be pretty tricky to implement for ObservableCollection.
What do you think? Is there any other way to have willSet / didSet for Observables without having to observe them? I like not having to observe my own local vars.

Nevermind, not a good idea. I'm closing this.


upload and display image

accomplished by https://github.com/thomasyimgit/CSS-filter/commit/737833db1e1cc7fed0cd04ea5e5373a5d8e02637


Error in safari

For some reason Safari went a bit crazy. Tested on Safari 15.2 and 16.1 and the problem is the same
The thing returned from await response.text() randomly is "[object Blob]" with a "typeof" – "string" on line https://github.com/prisma-labs/graphql-request/blob/33b82117d66a678952270e6bae34bd5ec79b80ab/src/index.ts#L667
I've used a custom serializer to debug this problem. Has anyone seen this before?

For anyone looking for a solution, i just passed the default fetch as an option. Culprit was somewhere around cross-fetch


'file' object has no attribute 'readable' error in version 1.5.0

I cannot submit any longer with the pypi kaggle commands. I get the following error:
$ kaggle competitions submit -c PLAsTiCC-2018 -f myfile.csv.gz -m 'mymessage'
  0%|                                                                                | 0.00/131M [00:00<?, ?B/s]
'file' object has no attribute 'readable'
Could not submit to competition

The file is readable. This is on CentOS Linux release 7.4.1708, with Python 2.7.
pip install kaggle --upgrade did not help. Since it looks like some progressbar, I tried uninstalling tqdm and reinstalling it, but that did not help either.

I can't reproduce this with either a plain csv or a zip. I tried it with the sample submission for the same competition.  We do not support Python 2 for the API, however.  I don't know for sure if that is the problem, but it's possible.

Apparently dput (https://salsa.debian.org/debian/dput) had a similar issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836456) They solved it with this patch:
-    if isinstance(stream, io.TextIOBase):
+    if isinstance(stream, file):
+        # Python 2 `file` type doesn't work with the `io` types. Open
+        # the file again with a type we can use.
+        if stream.mode.endswith('b'):
+            text_mode = stream.mode[:-1]
+        else:
+            text_mode = stream.mode
+        fileno = os.dup(stream.fileno())
+        result = io.open(fileno, mode=text_mode, encoding=encoding)
+    elif isinstance(stream, io.TextIOBase):
         result = stream

It has something to do with IO streaming.
This used to work a a few weeks ago.

Found a simple fix, see PR.

I merged that in, but please be aware that I'm generally not going to make any changes to accommodate Python 2.


Added .container-fluid to .content elements

This small change can be done because .content is extending .container-fluid.
Also it reduces number of lint erros in #652 from 163 to 75

Since .content works in place of .container-fluid, I don't see the reason for adding the extra class. If it's just because of the Bootstrap guidelines, it is not critical to follow them since it doesn't break the layout in any way.
I appreciate the contribution and apologize for any inconvenience! :+1:

@almasaeed2010 actually it doesn't. when you don't use .container or .container-fluid you must explicitly define .col-xs-12 on cols if you want them to maintain default bootstrap behavior.


[BUG] bismillah broken

https://quran.com/40
Regression introduced.

yep, this is because i am not done with https yet.
some of the things left:

static needs to be https
verses needs to be https
setting for cdn needs to be set to https

(it's not a code bug, it's just that because i haven't updated the cdn to be https yet, chrome fails to load the font since you're going from something https to http, which is considered insecure).


SCP-1890 refactor type reduction machinery + implement CC machine

In this PR

refactor reduction, progress, val 'xor' reduction, and determinism proofs to use frames.
Define CC machine.

For later:

Prove equivalence of CC machine and reduction.
Refactor CK machine to be relational.
Prove equivalence of CC and CK machine.

1 & 2 make use of evaluation contexts, which gives a direct connection. Although they are a bit annoying in Agda.
5 hinges on proving that stacks are isomorphic to evaluation contexts.

Pre-submit checklist:

Branch

[ ] Commit sequence broadly makes sense
[ ] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages

PR

[ ] Self-reviewed the diff
[ ] Useful pull request description
[ ] Reviewer requested

If you updated any cabal files or added Haskell packages:

[ ] nix-shell shell.nix --run updateMaterialized to update the materialized Nix files
[ ] Update hie-*.yaml files if needed

If you changed any Haskell files:

[ ] nix-shell shell.nix --run fix-stylish-haskell to fix any formatting issues

If you changed any Purescript files:

[ ] nix-shell shell.nix --run fix-purty to fix any formatting issues

Pre-merge checklist:

[ ] Someone approved it
[ ] Commits have useful messages
[ ] Review clarifications made it into the code
[ ] History is moderately tidy; or going to squash-merge

I added a variation on reduction using evaluation contexts and experimented with defining closing an evaluation context functionally and inductively.


change the influx.conf

i use influxd config > influx.conf get the config file, how can i do to change the file, and make i work. i change the file and mv the file to /opt/influxdb/, but it is not work.

if you run ./opt/influxdb/influxd -config /opt/influxdb/influx.conf it should start with the confi file at the given path.

@kcrosswind what @jhorwit2 said is spot on.


[BUG] - Graph labels not showing

Description
Labels don't show up below the graoh for as often as set in the settings, when the time interval is not set to year.
Android version
Android 10
Reproduction steps
No response
Screenshots
No response
App debug info
No response

combining with #145


[Bug]: Not working with @typescript-eslint/parser v8

Is there an existing issue for this?

[X] I have searched the existing issues and my issue is unique
[X] My issue appears in the command-line and not only in the text editor

Description Overview
Due to : https://github.com/typescript-eslint/typescript-eslint/pull/8933
accessing "typeParameters" will now be undefined.
It needs to be changed to "typeArguments" (and the other deprecations in the Pr linked above).
Expected Behavior
The result is that eslint-pugin-react doesn't find any declared props in a typescript project.
I see there is a PR to fix this: https://github.com/jsx-eslint/eslint-plugin-react/pull/3788 but it is about the deprecations, not the fact that eslint-plugin-react just stops working without any indication why (no errors from npm etc.)
eslint-plugin-react version
7.35.0
eslint version
v8.57.0
node version
v22

Note also - typescript eslint v8 is required for eslint v9, so this essentially blocks eslint v9 upgrade even though you now technically support it.

This isn't really a bug, to be clear, it's just something we don't support yet - and that shouldn't be surprising since it was just released like 24 hours ago.
Indeed, #3629 blocks supporting v6, and then we can work on v7 and then v8.

Sure - I raised this because it took me a while to figure out what was happening and having an issue open on GitHub might help other people.


Onboarding Docs are seriously anti-"Production Ready"

Titles:

Onboarding Docs seriously anti- "Production Ready"
Show OOP style in py-getting-started & direct towards a particular tutorial at end

Situation

Just discovered this: reusable-ui-components
after seeing class based flet UI tutorial on video: iYP6l1FYd-Y by "Mr. Newton"

Prior to this,

I had completed the Flet Introduction, and python-getting-started
both of which show the flet-app done the procedural way.
I had almost given up on flet due to this completely POP approach which became impossibly hard to even grasp on trying to apply.
and I did started doing Flutter
... which starts at this tutorial: first-flutter-app which teaches things the OOP way right from start....

Problem
Point I am trying to make is:

this flow of docs given below does NOT make any sense to a newcomer.

it first teaches it all in the POP way, then doesn't even mention about OOP way, and leaves the learner hanging in between.
only for per to eventually decide it's too complicated to manage, and leave.

the person is not guided towards a particular proper tutorial at any place.
the tutorials don't have any order numbering, nor a "start here" label at the tutorial picker page.

even the tutorials - I am assuming the Python - To-Do to be the first one - starts again from scratch from installing flet; a step already covered in the introduction

oh, and the "how-it-works" doesn't even get any surface it seems.

- "0. Introduction"             (example 1: counter :: POP)
> "Tutorials > Want to learn how to build a real app?"
(tutorials? yes yes, sure please :))

> "1. Py Getting Started"       (example 2: Name input :: POP)
(hmm, Tutorial & Getting Started, sounds same :D let's proceed :))

> "but it's a matter of personal preference :)"
(umh, is that it? doesn't feel like it.)
(wow, such an abrupt stop! where to go next?)

> "Testing on iOS"
(whattt? oh it's flet-python documentation)

> "Tutorials"
(so many, umh which one to pick now??)
<trying randomly>

> "Python To-Do"
(OOP - the right way) ...

Let's Talk Solutions

show the how-it-works inside introduction to showcase those advantages to the technically acquaint person.

move the Flet app example and below sections from introduction to a new (next) page with "minimal" added in the title.
smth like "Flet app minimal example" or "Flet minimal example"

[SALT]: Are you sure about the planned ""multilanguage support"?
This will make docs etc a lot more involved and require lots of redundant/repeated work.

[cntinued]: Some way to compile to different targets seems worth trying.
See shen Yggdrasil - it will cover python, C/C++, JVM (java vm), JS (JavaScript), & Lisp in one go.

[Anyways, B2TT]: Add a successor page (or section) to py-getting-started aimed at converting the POP code obtained at that point into OOP styled.

At the end of it, refer to one particular tutorial - say, the python-todo

At the end of that, refer to the tutorial picker page.

Thanks for your feedback!
So, you feel OOP way would be more preferable by fellow developers vs POP way?
Re: "multilanguage support" - that was the "grand" idea - to allow doing Flet from multiple languages, but currently it's unreachable goal. Python is so huge and adopting Flet for a different language is like starting all over again.

you feel OOP way would be more preferable by fellow developers vs POP way?

yes, the reasons can't be put in better words than the Flet documentation itself:
reusability, clarity & manageability.
it also makes it more inline with flutter.
https://github.com/flet-dev/website/blob/c5ab4c46a5a902e53c2e5d49a7ece601a6009293/docs/tutorials/python-todo.md#L124-L128

OK, will give it a thought. Definitely, docs require improvements!


Update testing.md

Link the fuzzer section to the appropriate source documetnation

Coverage remained the same at 98.653% when pulling 75a66200cbd54c86c53c2c127d187174cda85bb3 on isaacbrodsky-patch-3 into f8a0a84340120652ed8b4350782861a1841a4fcb on master.


lookAt turns in the closest direction.

Details
LookAt often did a 350 degree turn instead of a 10 degree turn in the other direction.

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

Hello, @dargonesti! Thanks for contributing to @egjs/view360.
Please check my above comments and below things, please!

I guess lint is missing in your code. Please set eslint in your IDE so our config can properly work. (CI is broken because of that!)
Please add some proper test codes related to your code.
Please sign the CLA :)


11.1.0 Dependency injection will not be able to resolve the parameters of FieldArrayType's constructor.

In Angular 11.1.0 you cannot extend FieldArrayType for now you can downgrade to 11.0.9.
I think this is an issue with Angular as it was working prior to 11.1.0. Just logging it here for anyone else who gets the error on the FieldArrayType
I logged the issue on the main Angular repo here.
https://github.com/angular/angular/issues/40532
Minimal Reproduction
this commit is working
vespertilian/angular-test-app-jasmine@5163dbd
this commit is not
vespertilian/angular-test-app-jasmine@fae6f38
^^^ two last commits in the master branch will let you toggle the scenarios

I think that's a regression better to wait for an Angular fix

I think that's a regression better to wait for an Angular fix

feel free to reopen if Angular doesn't provide a fix.

feel free to reopen if Angular doesn't provide a fix.

From https://github.com/angular/angular/issues/40532

I looked into your statement that ngx-formly does have the @Directive decorator applied, but this is not the case for version 5.10.12 that is latest on NPM. The decorator is only present on the master branch, but I suspect that hasn't yet been released. The simplest workaround would be to add that directive also to the 5.x branch of ngx-formly.

I did check the master branch and you have added the decorator. So we just need to pull it into the 5.x branch?

From https://github.com/angular/angular/issues/40532

I looked into your statement that ngx-formly does have the @Directive decorator applied, but this is not the case for version 5.10.12 that is latest on NPM. The decorator is only present on the master branch, but I suspect that hasn't yet been released. The simplest workaround would be to add that directive also to the 5.x branch of ngx-formly.

I did check the master branch and you have added the decorator. So we just need to pull it into the 5.x branch?

the problem still exists!!!

the problem still exists!!!

@vespertilian would you like to work on this?

@vespertilian would you like to work on this?

As far as I understand everything is already in the main branch, the only thing we should do is to make a release ? Am I correct ?

As far as I understand everything is already in the main branch, the only thing we should do is to make a release ? Am I correct ?

Oh btw, another workaround could be to add an explicit constructor in the subtype, as then you avoid the necessity for the base class to have an Angular decorator.

Oh btw, another workaround could be to add an explicit constructor in the subtype, as then you avoid the necessity for the base class to have an Angular decorator.

I see, so I think removing FieldArrayType decorators which was used to show deprecation would solve the issue then!

I see, so I think removing FieldArrayType decorators which was used to show deprecation would solve the issue then!

I see, so I think removing FieldArrayType decorators which was used to show deprecation would solve the issue then!

I'm not sure I understand; FieldArrayType should retain its @Directive() decorator as it extends from a class with Angular behavior. So the master branch is currently correct.

I see, so I think removing FieldArrayType decorators which was used to show deprecation would solve the issue then!

I'm not sure I understand; FieldArrayType should retain its @Directive() decorator as it extends from a class with Angular behavior. So the master branch is currently correct.

@aitboudad Happy to help out in any way I can, but as I understand it we just need to make the 5.x branch match the main branch that has FieldArrayType with an @Directive() decorator, so can we (you) just pull that in and release it? Or would you like a separate PR for the 5.x branch? I can do that if you like. Just let me know.

@aitboudad Happy to help out in any way I can, but as I understand it we just need to make the 5.x branch match the main branch that has FieldArrayType with an @Directive() decorator, so can we (you) just pull that in and release it? Or would you like a separate PR for the 5.x branch? I can do that if you like. Just let me know.

This issue has been fixed and released as part of v5.10.13 release.
Please let us know, in case you are still encountering a similar issue/problem.
Thank you!

This issue has been fixed and released as part of v5.10.13 release.
Please let us know, in case you are still encountering a similar issue/problem.
Thank you!


Refactor CLI query/filter mechanism

This is a non-functional refactoring, which improves the filter/query mechanism of the CLI (e.g. klog total --since 2022-04-15).

The queries are composed of individual matchers now, which will allow for more complex query use-cases in the future, like grouping/stacking filter expressions, or combining them via “or” or “not” instead of just “and”.
Potentially redundant filter flags are interpreted strictly now. Before, when passing both --since and --last-week, the former was silently skipped. Now, all flags are respected.

I’ve realized that this approach doesn’t work properly, unfortunately. I’ll give it another pass later.


Refactor the replication connections

Problem to solve

FD leak caused by client side not draining from the read stream. (related fixes: https://github.com/uber/cherami-server/pull/265, https://github.com/uber/cherami-server/pull/266)
Bug on shutdown path that is causing sealed message not made to store.

Design philosophies
read pump reads from stream, write pump writes to stream
read pump communicate with write pump using an internal channel. Read pump writes to the internal channel, and write pump reads from it
Graceful shutdown sequence:

read pump gets a read error (remote shuts down the connection)
read pump closes the internal channel, then exits
write pump detects the internal channel is closed
write pump calls stream.Done(), and exits

Other changes
Removed the error handling cases in OutConn.go since same error handling is also done in store. Now replicator serves as a proxy only.

Coverage decreased (-0.05%) to 67.267% when pulling dea872bd9bea2201b80b1349482897e7203c40de on rr_f into 2a2575a5511e3f7d21f67e48d2b7711081649942 on master.

Coverage increased (+0.2%) to 67.497% when pulling dea872bd9bea2201b80b1349482897e7203c40de on rr_f into 2a2575a5511e3f7d21f67e48d2b7711081649942 on master.

@kirg For the empty credit case(https://github.com/uber/cherami-server/pull/280/files#diff-f8daca02f7ff8d4e7df757fe00f19bc4L148), I think we can rely on the idle timeout(creditFlowTimeout) to eventually close the pumps, instead of introducing another notification channel.

Coverage increased (+0.1%) to 67.452% when pulling 152bd6bf22c7b9f778f1c8ee66de7ee34ef55369 on rr_f into 2a2575a5511e3f7d21f67e48d2b7711081649942 on master.

Coverage increased (+0.3%) to 67.652% when pulling 646aba39a743619ab91551190d6e39b3a8eaf043 on rr_f into 2a2575a5511e3f7d21f67e48d2b7711081649942 on master.

Coverage increased (+0.1%) to 67.466% when pulling 646aba39a743619ab91551190d6e39b3a8eaf043 on rr_f into 2a2575a5511e3f7d21f67e48d2b7711081649942 on master.


Energy Calculator

Calculator Functions
This issue creates a energy calculator for lights using HTML, CSS and JS
@vasu-1, kindly assign this issue to me.
Contribution Event
GSSOC22
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign


clear up max_size docs and have code match the docs

Closes #781

Working through test failures, it looks like the max value for max_size is also based of the size of one dimension. Should [this] be squared as well?

Just upgraded my node-mapnik to the 3.0.x branch and am getting a max_size related error. Namely, for some large maps rendered with the Map.render or Map.renderSync, I get an Error: Invalid width for image dimensions requested. These maps rendered perfectly fine previously. I'm not sure how to address. Is there a way to globally set the max_size constraint because that would likely be simplest.

@davenquinn my intuition is that your issue is different that what this PR is attempting to fix. Your error is coming from mapnik core: https://github.com/mapnik/mapnik/blob/v3.0.x/include/mapnik/image_impl.hpp and indicates that an image larger than 65535x65535 is being allocated (https://github.com/mapnik/mapnik/blob/v3.0.x/include/mapnik/image.hpp#L77).

OK thanks, that's really big, much larger than the image I'm trying to produce. I'll look in the mapnik 3.0.13 > 3.0.16 transition to see what might have caused that in core.

This is stale and looking back at this I'm not totally convinced its a necessary change. @mcwhittemore if you feel otherwise feel free to re-open a new ticket, but for now I'll close this one.


How to use rust-tools with mason-lspconfig?

Is there a minimal configuration example of setting up mason-lspconfig and rust-tools together anywhere? I checked both this repo and mason but I did not find it?
I just want to know the 'correct' way to setup a vim config with mason, where mason loads not exclusively just rust_analyzer, and rust_analyzer itself has a few custom settings + rust-tools. Codelldb/debugging optional but welcome, as I believe you can set it up pretty nicely?
Would love to see this actually written out somewhere, e.g. a readme or wiki.

If you're fine with using nvim-lspconfig, you can refer to my setup: https://github.com/utkarshgupta137/nvim-lazy/blob/73a2a2f/lua/lvim/lsp.lua#L20 + https://github.com/utkarshgupta137/nvim-lazy/blob/73a2a2f/lua/lvim/lsp/rust-tools.lua
AFAIK, there is no benefit of setting up LSP using mason-lspconfig over nvim-lspconfig.

The trick I found was to avoid setting up anyting rust related in mason-lspconfig
            require("mason-lspconfig").setup_handlers {
                function(server_name)
                    require("lspconfig")[server_name].setup {}
                end,

                ["rust_analyzer"] = function() end
            }

I then have rust-tools setup everything using mason paths by it self
            local install_root_dir = vim.fn.stdpath "data" .. "/mason"
            local extension_path = install_root_dir .. "/packages/codelldb/extension/"
            local codelldb_path = extension_path .. "adapter/codelldb"
            local liblldb_path = extension_path .. "lldb/lib/liblldb.so"
            local rt = require("rust-tools")
            rt.setup({
                tools = {
                    hover_actions = {
                        -- whether the hover action window gets automatically focused
                        auto_focus = false,
                    },
                },
                server = {
                    on_attach = function(_, bufnr)
                        require("dap")
                        require("dapui")
                        -- Hover actions
                        vim.keymap.set("n", "K", rt.hover_actions.hover_actions, { buffer = bufnr })
                        -- Code action groups
                        -- vim.keymap.set("n", "<Space>a", rt.code_action_group.code_action_group, { buffer = bufnr })
                    end,
                    flags = {
                        debounce_text_changes = 150,
                    },
                    settings = {
                        ["rust-analyzer"] = {
                            checkOnSave = {
                                enable = true,
                                command = "clippy",
                            },
                            cargo = {
                                allFeatures = true,
                            },
                        },
                    },
                },
                dap = {
                    adapter = require("rust-tools.dap").get_codelldb_adapter(codelldb_path, liblldb_path),
                },
            })

I setup the keybindings on the LspAttach event (in the nvim-lspconifg in my lazy config), so they are common for all LSP

@snaggen Thank you very much, that is nice!
After reading what that setup_handlers does in the mason lsp config docs, I noticed it actually explicitly mentions rust-tools as a handler itself: https://github.com/williamboman/mason-lspconfig.nvim/blob/main/doc/mason-lspconfig.txt#L163
So I guess that is the intended way, I will try this approach.
Would still like a mention of that at least in this repo perhaps.

For anyone stumbling upon this in the future, this is the setup I went with:
local rust_tools_config = {
	-- rust-tools settings, etc.
	dap = function()
		local install_root_dir = vim.fn.stdpath "data" .. "/mason"
		local extension_path = install_root_dir .. "/packages/codelldb/extension/"
		local codelldb_path = extension_path .. "adapter/codelldb"
		local liblldb_path = extension_path .. "lldb/lib/liblldb.so"

		return {
			adapter = require("rust-tools.dap").get_codelldb_adapter(codelldb_path, liblldb_path)
		}
	end,
}

mason_lspconfig.setup_handlers({
	-- The first entry (without a key) will be the default handler
	-- and will be called for each installed server that doesn't have a dedicated handler.
	function(server_name)
		-- I use lsp-status which adds itself to the capabilities table
		require("lspconfig")[server_name].setup({ on_attach = on_attach, capabilities = capabilities })
	end,

	["lua_ls"] = function()
		require("lspconfig").lua_ls.setup({
			on_attach = on_attach,
			capabilities = capabilities,
			settings = {
				Lua = {
					diagnostics = {
						-- Get the language server to recognize the `vim` global
						globals = { "vim" },
					},
				},
			},
		})
	end,

	["rust_analyzer"] = function()
		require("rust-tools").setup({
			-- rust_tools specific settings
			tools = rust_tools_config,
			-- on_attach is actually bound server for rust-tools
			server = rust_tools_rust_server,
			capabilities = capabilities,
		})
	end,
})

(full config here: https://github.com/Gremious/configs, though it's still a mess)

(full config here: https://github.com/Gremious/configs, though it's still a mess)

It looks like that is a private repo or deleted

-- I use lsp-status which adds itself to the capabilities table

It looks like the capabilities variable doesn't exist, can you elaborate?

It looks like that is a private repo or deleted

Oops, my bad! Public now.

It looks like the capabilities variable doesn't exist, can you elaborate?

If you mean variable doesn't exit in my little snippet - yeah, sorry. I believe you can ommit it if you're not doing anything special.
But you can see it here: https://github.com/Gremious/configs/blob/main/lua/config/lsp.lua#L110
I create cmp_nvim_lsp ones from the lsp default ones, with the function cmp_nvim_lsp provides.
Then, I extend the table with lsp_status ones as well.
If you mean Mason doesn't mention the capabilities table, then yeah, mason-lspconfig doesn't mention on_attach/capabilities anywhere at all, but they are necessary, so I assume those are just the actual nvim-lspconfig tables, since nvim-lspconfig (not mason) notes "You must pass on_attach and capabilities for each setup {} if you want these to take effect." in their readme https://github.com/neovim/nvim-lspconfig

For anyone on macOS, you need to do two things:

Use these instructions to symlink lldb-vscode onto your path without conflicting with the default lldb installation.
Change the end of the liblldb_path to .dylib.

Thanks a lot for the help!
This is what I decided to go with after getting the same error
require('mason-lspconfig').setup_handlers({
  function(server_name)
      require("lspconfig")[server_name].setup({ on_attach = on_attach, capabilities = capabilities })
    end,

    ["rust_analyzer"] = function ()
        require("rust-tools").setup()
    end
})

Thanks a lot for the help!
This is what I decided to go with after getting the same error
require('mason-lspconfig').setup_handlers({
  function(server_name)
      require("lspconfig")[server_name].setup({ on_attach = on_attach, capabilities = capabilities })
    end,

    ["rust_analyzer"] = function ()
        require("rust-tools").setup()
    end
})

works well enough 😅

This have the downside of always loading rust-tools, so to get it lazy loaded I instead uses
                ["rust_analyzer"] = function() end

in the mason-lspconfig.
And then I just load it using a file type trigger in my Lazy config
 {
        -- Rust Programming Enhancements
        "simrat39/rust-tools.nvim",
        ft = "rust",

        ...
}

that's actually quite smart 😄

Could someone add this to the README?


Disable allowAnalytics by default

In order to conform with data protection regulation (the principle of Privacy by Default in the GDPR) I'm disabling analytics.

I'm not opposed to this change, however we will lose a lot of valuable insight that we use to improve Kap. We don't collect any PII and the data is not used for any sort of identification or tracking, GDPR conditions for consent (Art. 7) explicitly governs personal data, defined as:
‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; (Art. 4)
You can read more about what kind of information we use and our implementation of analytics in our privacy policy. We take a lot of care to only collect the information we actually need and to retain that information for the shortest possible time.

I assumed that the data could identify a person (device identifiers, IP address, etc.), in which case I would prefer opt-in, but it's great to hear that you don't process any personal data.
Perhaps the description below the "Allow analytics" option should link to the privacy policy?

Good idea! We'll make sure to add a link to the privacy policy in the next update. For the record we do not collect IP addresses or any kind of device identifiers.


draft for multiple seat maps

I agree of the need to do this change. It makes it possible to fetch placeMap avialability for different types of reservations in one hit. It also opens up the possibility to make an upgrade from 2:nd class to 1:st class in a good way. That is good.
Our real need is to have the possibility of adding a selection-fee when selecting seat from placeMap, and the fee can be different for different places as well.
IMS can rank the places internally and add different fee amounts depending of the place-rank to the place-map availability response .
It is easy for the distributor to show the customer the extra fee on each place (if any).

At booking with placeSelections, the IMS add the proper fee for the place to the reservation or not depending of selected place.
The selection fee shall be tight connected (by reference) to the reservation to make it easier to handle it at delete and refund of the reservation.
This behavior to charge some extra when selecting from a place-map is quite common and popular for commercial express bus companies and there is also examples in the rail industry (Flix train). To add a optional placeMapSelectionFeeAmount to the PlacePostions structure would in our opinion make it easy for both distributors and providers to handle this.
The alternative is to define different reservationOfferParts for different accommodationSubType (one with a fee and one without the fee) for each place. In case of different fees on different places this can expand to a big number of different accommodationSubTypes.
For the distributor it will be complicated to choose the right reservationOfferPart with the correct accomodationSubTypes in case of not selecting place.
When rendering the place-map for a coach, several availability/place-map responses must be merged into one common place-map.

I agree of the need to do this change. It makes it possible to fetch placeMap avialability for different types of reservations in one hit. It also opens up the possibility to make an upgrade from 2:nd class to 1:st class in a good way. That is good.
Our real need is to have the possibility of adding a selection-fee when selecting seat from placeMap, and the fee can be different for different places as well.
IMS can rank the places internally and add different fee amounts depending of the place-rank to the place-map availability response . It is easy for the distributor to show the customer the extra fee on each place (if any).
At booking with placeSelections, the IMS add the proper fee for the place to the reservation or not depending of selected place.
The selection fee shall be tight connected (by reference) to the reservation to make it easier to handle it at delete and refund of the reservation.
This behavior to charge some extra when selecting from a place-map is quite common and popular for commercial express bus companies and there is also examples in the rail industry (Flix train). To add a optional placeMapSelectionFeeAmount to the PlacePostions structure would in our opinion make it easy for both distributors and providers to handle this.
The alternative is to define different reservationOfferParts for different accommodationSubType (one with a fee and one without the fee) for each place. In case of different fees on different places this can expand to a big number of different accommodationSubTypes.
For the distributor it will be complicated to choose the right reservationOfferPart with the correct accomodationSubTypes in case of not selecting place.
When rendering the place-map for a coach, several availability/place-map responses must be merged into one common place-map.

The indication in the reservationfferPart that a graphical selection is provided is included in availablePlacePreferences. This allows a fee fo reserations with graphical reservation.

The indication in the reservationfferPart that a graphical selection is provided is included in availablePlacePreferences. This allows a fee fo reserations with graphical reservation.


fix: not a valid entry warning thrown by mason-lspconfig

A new commit in mason-lspconfig.nvim https://github.com/williamboman/mason-lspconfig.nvim/pull/81 warns about invalid entries in ensure_installed, and I got warnings from :Notifications like:
Server bash-language-server is not a valid entry in ensure_installed. Make sure to only provide lspconfig server names.
Server lua-language-server is not a valid entry in ensure_installed. Make sure to only provide lspconfig server names.

So I replace the server name with name in available-lsp-servers.

LGTM. Those lsp name are names for mason-tool-installer, and shouldn't be used in mason-lspconfig.


Add opam master (opam-dev + opam-2.2) to the base images

To make it easy to test opam master regularly it would be really handy to have an opam-dev binary around in the docker images.

A thought - perhaps put the master build as /usr/bin/opam-2.2 and, while the branch doesn't exist and also hard-link /usr/bin/opam-dev to it. Then when opam actually branches 2.2, things which were assuming opam-2.2 carry on working (that binary switches to tracking the 2.2 branch) and either /usr/bin/opam-dev is a direct build of master or (more likely) we immediately have /usr/bin/opam-2.3 and the same dance for opam-dev?

my reasoning is that opam-dev will always be the latest dev version, clients won’t have to change every time there is a new version. This binary will be always useful to have around.
If the opam-2.2 binary is opam-master, it makes it more annoying to update as we’d have to remember to update docker-base-images at branch time, especially as it will (even briefly) become 2.3.0~alpha~dev around that time. It wouldn’t make much sense.
I’d much rather have opam-2.2 only when it branches so people know it’s more stable to use.

My reasoning was kinda the opposite 🙂 With the possibly sole exception of actually wanting to test whether opam master has broken something, most users would want to switch to a master branch because they want a feature in advance - i.e. they want opam 2.2 right now but it's not released yet, so when we branch 2.2 that workflow carries on working. Having opam-2.2 facilitates more workflows, rather than fewer. We (CI-side) should be ensuring that docker-base-images is updates at branch time already - even automatically at some point.

(Note that I'm also suggesting that opam-dev is always the dev version, too)

Then let’s settle on a middle ground: Why not have both? We can have both:

opam-2.2: currently pointer to master, for people who want features early but don’t want to break in the future
and opam-dev: for people who are willing to be broken in the future and always want the latest.

We appear to have been arguing in agreement because your last comment is what I thought I was proposing 🙂

ah indeed, I missed the and also hard-link /usr/bin/opam-dev to it part. My bad...

Ready to go now.


Fixed bug in CompilePartVisitor not using Encoders.HtmlEncode

This made it impossible to disable HTML escaping for compiled templates.
The fix itsel is in Nustache.Compilation/CompilePartVisitor.cs  where I modified the reflecting code to look up the HtmlEncoder delegate set.
Btw. this fixed most of Interpolation* test cases too (they run green after the patch - in my case at least)

Hey,
Thanks for submitting this, I've taken a look and it looks fine to me. I'll include it in the next release which should come out at latest by Friday,
Thanks!


add two attrs for _MklBatchMatMulV2 and _MklMatMul to fix matmul rela…

…ted failed unit tests

Missed this denorm commit for the QA-rocm57 branch


start and build should have an option for reseting the git repo

currently they automatically reset the git repo and do a pull, this should be optional

Updated feature in branch feature/586 -- however, still getting those dang errors when listing inventory and obtaining status. Will take a look at these later.


Account-Slots

Coverage decreased (-2.1%) to 79.643% when pulling 3356cc764a940c555f2ab6d3db6fd16ab33eea6c on dev into 12f1e5599e646c22ca4010df9745b047e60f6aab on master.

Coverage increased (+0.6%) to 82.414% when pulling a6eb991b7f8b1bdaa77161fee447e40b287d8689 on dev into 12f1e5599e646c22ca4010df9745b047e60f6aab on master.


Revert status to "initial" for 3 FOMs

Describe the task
Revert status to "initial" for 3 FOMs:

1282
1289
1290

Acceptance Criteria

[x] completion of this task is communicated to Julius

Additional context


client send data to server got "more than 125 octets"

Describe what you would like to know or do
Occasionally, an error occurs (more than 125 octets) when the client sends data to the server
Describe the solution you'd considered
how to avoid it?
Additional context
Our scenario is the transmission of binary voice data through websocket

Please provide StR

2022-07-17 22:29:17.696 ERROR [WebSocketConnectReadThread-2409] o.j.WebSocketImpl 410 - Closing due to invalid data in frame
org.java_websocket.exceptions.InvalidFrameException: more than 125 octets
at org.java_websocket.drafts.Draft_6455.translateSingleFramePayloadLength(Draft_6455.java:619)
at org.java_websocket.drafts.Draft_6455.translateSingleFrame(Draft_6455.java:547)
at org.java_websocket.drafts.Draft_6455.translateFrame(Draft_6455.java:762)
at org.java_websocket.WebSocketImpl.decodeFrames(WebSocketImpl.java:398)
at org.java_websocket.WebSocketImpl.decode(WebSocketImpl.java:233)
at org.java_websocket.client.WebSocketClient.run(WebSocketClient.java:516)
at java.lang.Thread.run(Thread.java:748)

It would be helpful if you could post the code that sends the data. If you can, dump the data with wireshark (without using SSL encryption) during the error so that we can see the problematic frame.

No StR


Added generalized dice score metric

What does this PR do?
Fixes #1089 . Didn't manage to make it work for multidimensional multilabel scenarios. However, that shouldn't a very common use case.
Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure to update the docs?
[x] Did you write any new necessary tests?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

I beilve that this shall be automatically resolved in cmd by git merge upstream/master

@jlcsilva shall be resolved now, pls check if I did not make a mistake... :rabbit:

@jlcsilva shall be resolved now, pls check if I did not make a mistake... 🐰

Seems ok to me.
Also, I know why the tests are failing, but I'm unsure about what to do. In the file tests/unittests/classification/inputs.py
I changed the data type of some input tensors, such as _input_binary, from int to float, to match the description here. Since the tests are failing, I'm not sure what's wrong, the documentation or the code. Any thoughts from someone with a better overall view of the repo?

Hi @jlcsilva, when looking at the changes in the PR there also seems to be some changes to other metrics. Any particular reason for this?

Hi @jlcsilva, when looking at the changes in the PR there also seems to be some changes to other metrics. Any particular reason for this?

In the StatScore class I added the None option for the reduce argument, which I needed for my generalized dice score implementation, and changed its documentation and that of its subclasses accordingly. Additionally, I corrected some typos and added some missing information to these classes' documentation.
Finally, I changes the data type of some test inputs to match that in the general input type documentation page, and added new multidimensional input tensors. To me, this seems to be what is making the code fail the tests. Currently, I'm out of office, but I'll check it as soon as I go back to work

Hey @SkafteNicki,
No problem! I've also been away, so wasn't able to help. I noticed the changes when I came back and pulled the repo again. I'm actually a bit busy today and next week, but let me know if there is something I can help with :)

@jlcsilva @SkafteNicki, mind checking the collisions after the refactor was merged... :)

@jlcsilva @stancld, mind checking the collisions after the refactor was merged... :otter:

@Borda I'll do rebase now.

ℹ It will be needed to add test cases after refactoring tests as a part of the classification refactor.

Going to take over this PR now so we hopefully can land it within the next week :]

Going to take over this PR now so we hopefully can land it within the next week :]

hi @SkafteNicki how is it going here? :)

@justusschock, how much need to be done? :chipmunk:

@jlcsilva, any chance you could work on this one, in particular, add some tests... :flags:

seems we hit some internal Gh issue, will be restarted later...


Cdxgen hangs without any debug message

Command:
SCAN_DEBUG_MODE=debug ./cdxgen-linux -t python /{my python project}
also tried:
SCAN_DEBUG_MODE=debug ./cdxgen-linux   /{my python project}
do not see any debug message and the process stuck there for hours.

@navulirs No idea. Are there any memory constraints? Could you given an idea from where you are running this command. Also you could try using the npm version?
sudo npm install -g @appthreat/cdxgen
cdxgen -t python <dir>

@navulirs are you still facing this issue?


[WIP] Updates before launch

Done:

bringing in latest changes from cloudalchemy/demo-site (commits are merged, squashed and signed)

switching caddy ansible role as old one moved to new home
minor fixes in README.md
extending storage retention to 31d

adding dev-sec framework roles to increase instance security
using python3 instead of python2
split group_vars/all into multiple groups for easier variables management
make playbooks more managable by moving them into playbooks/ directory and linking everything from top-level site.yml playbook
update site logo to prometheus one
switch from travis to cricleci
fix links in readme and in index.html
remove unused vault variable related to influxdb
move grafana target definition from file_sd to static target (it didn't make any sense before)
specify scp as a default ansible copy method. This isn't necessary, but it removes warning about sftp connection problems as sftp is disabled by ssh-hardening role
add downloading role requirements in deploy.sh script and move script to top-level directory
move webserver variables from playbook into group_vars/web

TODO:

test ssh access from circleci
test deployment of random_exporter using circleci (golang required)
add DNS names
figure out secure decrypting of ansible vault in circleci
add SSH pub key of circleci machine to DO and to VM
destroy VM and redeploy from scratch

/cc @SuperQ

One request, can we name the group_vars files with .yml extension?

Good idea :+1:


Bug: serializeRecursively` attempts to serialize an array reference to a callable

sentry/sdk^2.2.0
php 7.4.10

When \Sentry\Serializer\AbstractSerializer::serializeRecursively($value) gets a value of the format [Foobar:class, 'methodName'] for a non-static method (ie a lazy callable like in League's router), it gets passed to \Sentry\Serializer\AbstractSerializer::serializeCallable(). On hitting that callable typed parameter, it will throw:
Deprecated: Non-static method Foobar::methodName() should not be called statically in /var/www/example/vendor/sentry/sentry/src/Serializer/AbstractSerializer.php on line 284

Solution: simply remove the callable type in \Sentry\Serializer\AbstractSerializer::serializeCallable(). I've tested it locally (haven't ran full tests though) and it seems to behave fine. The rest of the function (with reflection etc) seems to be handling things properly.

Sidenote: because of the use if is_callable(), some values like a string named mail may return true even if they're just plain strings. That's sort of an edge case and I'm not sure if anything can be really done about it in this context. It won't error so probably not much of an issue.

Duplicate of #815. I thought we fixed it somehow in 2.2.3 :confused:

@tdtm can you check the sentry/sentry-php version you're using? 2.2.3 should contain the needed fix.

That would be sentry/sentry in my lockfile, right? I've got 2.5.0. I'm requiring `sentry/sdk^2.2.0.
It resolves to this in my lockfile:
		{
            "name": "sentry/sdk",
            "version": "2.2.0",
            "source": {
                "type": "git",
                "url": "https://github.com/getsentry/sentry-php-sdk.git",
                "reference": "089858b1b27d3705a5fd1c32d8d10beb55980190"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/getsentry/sentry-php-sdk/zipball/089858b1b27d3705a5fd1c32d8d10beb55980190",
                "reference": "089858b1b27d3705a5fd1c32d8d10beb55980190",
                "shasum": ""
            },
            "require": {
                "http-interop/http-factory-guzzle": "^1.0",
                "sentry/sentry": "^2.5",
                "symfony/http-client": "^4.3|^5.0"
            },
            "type": "metapackage",
            "notification-url": "https://packagist.org/downloads/",
            "license": [
                "MIT"
            ],
            "authors": [
                {
                    "name": "Sentry",
                    "email"<EMAIL_ADDRESS>                }
            ],
            "description": "This is a metapackage shipping sentry/sentry with a recommended HTTP client.",
            "homepage": "http://sentry.io",
            "keywords": [
                "crash-reporting",
                "crash-reports",
                "error-handler",
                "error-monitoring",
                "log",
                "logging",
                "sentry"
            ],
            "funding": [
                {
                    "url": "https://sentry.io/",
                    "type": "custom"
                },
                {
                    "url": "https://sentry.io/pricing/",
                    "type": "custom"
                }
            ],
            "time": "2020-09-14T09:30:55+00:00"
        },
        {
            "name": "sentry/sentry",
            "version": "2.5.0",
            "source": {
                "type": "git",
                "url": "https://github.com/getsentry/sentry-php.git",
                "reference": "bab5b73dbaf5f0ff62317e1611d952764d5514a9"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/getsentry/sentry-php/zipball/bab5b73dbaf5f0ff62317e1611d952764d5514a9",
                "reference": "bab5b73dbaf5f0ff62317e1611d952764d5514a9",
                "shasum": ""
            },
            "require": {
                "ext-json": "*",
                "ext-mbstring": "*",
                "guzzlehttp/promises": "^1.3",
                "guzzlehttp/psr7": "^1.6",
                "jean85/pretty-package-versions": "^1.2",
                "php": "^7.1",
                "php-http/async-client-implementation": "^1.0",
                "php-http/client-common": "^1.5|^2.0",
                "php-http/discovery": "^1.6.1",
                "php-http/httplug": "^1.1|^2.0",
                "php-http/message": "^1.5",
                "psr/http-factory": "^1.0",
                "psr/http-message-implementation": "^1.0",
                "psr/log": "^1.0",
                "symfony/options-resolver": "^2.7|^3.0|^4.0|^5.0",
                "symfony/polyfill-uuid": "^1.13.1"
            },
            "conflict": {
                "php-http/client-common": "1.8.0",
                "raven/raven": "*"
            },
            "require-dev": {
                "friendsofphp/php-cs-fixer": "^2.16",
                "monolog/monolog": "^1.3|^2.0",
                "php-http/mock-client": "^1.3",
                "phpstan/extension-installer": "^1.0",
                "phpstan/phpstan": "^0.12",
                "phpstan/phpstan-phpunit": "^0.12",
                "phpunit/phpunit": "^7.5.18",
                "symfony/phpunit-bridge": "^4.3|^5.0",
                "vimeo/psalm": "^3.4"
            },
            "suggest": {
                "monolog/monolog": "Allow sending log messages to Sentry by using the included Monolog handler."
            },
            "type": "library",
            "extra": {
                "branch-alias": {
                    "dev-master": "2.5.x-dev"
                }
            },
            "autoload": {
                "files": [
                    "src/functions.php"
                ],
                "psr-4": {
                    "Sentry\\": "src/"
                }
            },
            "notification-url": "https://packagist.org/downloads/",
            "license": [
                "BSD-3-Clause"
            ],
            "authors": [
                {
                    "name": "Sentry",
                    "email"<EMAIL_ADDRESS>                }
            ],
            "description": "A PHP SDK for Sentry (http://sentry.io)",
            "homepage": "http://sentry.io",
            "keywords": [
                "crash-reporting",
                "crash-reports",
                "error-handler",
                "error-monitoring",
                "log",
                "logging",
                "sentry"
            ],
            "funding": [
                {
                    "url": "https://sentry.io/",
                    "type": "custom"
                },
                {
                    "url": "https://sentry.io/pricing/",
                    "type": "custom"
                }
            ],
            "time": "2020-09-14T07:02:40+00:00"
        }


Identify and track problems or obstacles that require changes to the process

We are running into disconnects where proposed changes to the solid process arrive as pull requests without traceability back to the original problem that led to the change. Additionally, we lack an accessible place to discuss the issue, or reference discussions about the issue that happened in any virtual or in-person meetings.

@justinwb could you add a process proposal pull request with this change


Provide a way to refer to extra jars in launch script classpath

Currently the launch scripts generated for controller and invoker refer to an explicit classpath which enumerates all the existing dependencies of these modules.
For certain scenarios its desirable to add custom jars to the classpath. For e.g. by default openwhisk bundles kamon-statsd but in our environment we need to use kamon-datadog. To enable that we need to include the kamon-datadog jars in controller classpath.
Proposal
To enable that launchscript can provide a wildcard pattern 'extra-libs/*'. Then in our custom image we can add extra jars to this directory which would get picked up at runtime
CLASSPATH=$APP_HOME/lib/akka-slf4j_2.11-2.5.6.jar:$APP_HOME/extra-libs/*

Possible Approach
Checking in Gradle it does not appear to provide a simple way to add such custom entry. (Raised query here). So for now we can go with an approach like here

Open PR #3059 for this.
To see usage refer to example which provides a custom docker image which extends whisk/controller and adds Kamon JMX support to it

Done via #3059


Performance tweaks

Mainly for https://github.com/yyuu/pyenv/issues/356.

Pretty cool :+1: Better performance would be really nice.
Although, separating bash processes would be better for simplicity even if it's not the best for performance. I'm not sure performance is how much important for pyenv since pyenv is basically a command-line tool and will be ran only if some python apps are invoked. Most of time would be consumed by application itself.

pyenv is basically a command-line tool and will be ran only if some python apps are invoked

Yes, but e.g. with Vim etc, python might be called several times, and then it adds up - especially with things like version checking during startup etc, which are expected to be really fast.
I guess this should be first discussed / agreed upon for rbenv.
(btw: see #360 for better merging in the future.. :octocat:)

@yyuu
Performance is merely an issue, if it gets called often, e.g. with Neovim, where the python interpreter is called multiple times during startup.  But also for things like displaying the pyenv/Python version in your prompt etc.
I've forwarded it to rbenv (https://github.com/sstephenson/rbenv/issues/736), and that seemed to trigger the "anyenv" rewrite in Go.. :)
That means that it won't make it into rbenv.
Given the common merge ancestor we now have, do you think it's worthwile for pyenv, until anyenv would/could replace it possibly?

I think we'd be better to wait for/contribute to anyenv. Until then, I want to keep this not merged to avoid unexpected compatibility issues....

Makes sense, closing it for now.


caml_bigint_256_to_bytes does not perform serialization

We have encountered this when providing documentation for the Rust implementation of Mina.
The caml_bigint_256_to_bytes function which is called by bin_prot when serializing the big integers of field elements takes a copy of the BigInteger256 structure without serializing it.
https://github.com/MinaProtocol/mina/blob/91d6d536345f7e313b73fcb78bdea657ff584b72/src/lib/marlin_plonk_bindings/stubs/src/bigint_256.rs#L109
This means that for hosts with different endianness bin_prot will produced different results.
Speaking with Matthew the code has a check to only allow Mina to run on little-endian machine.   Thus, the protocol packets have field elements in little-endian.
In order to proceed with any 3rd party implementations we need to agree on the correct network representation for the various protocol messages and types.  For big integers there are a few possibilities:

Use big-endian (aka network byte order) everywhere
Use little-endian everywhere
Use whatever the current mainnet uses (could be a mixture)

(1) is what's normally used by protocols, but this would require a lot of code changes and could be complex and disruptive to release
(2) the same as (1), but use little-endian, which is uncommon for network order
(3) would be the least disruptive change to the code
We need to decide which path to take.
If we chose (3), then since the protocol currently uses little-endian for field elements we would stick with this.  If so, then we could update caml_bigint_256_to_bytes to call the canonical serialization available in the marlin code for BigInteger256.  The result should be that both little-endian and big-endian machine both serialize big integers through bin_prot the same way.

@psteckler and I discussed something similar shortly before mainnet, but we found we couldn't (at least, easily) change the serialisation of field elements without changing the encodings of public keys etc. At the time, we decided to stick with the status quo to avoid changing the format of public keys after people had already generated theirs.
That's not to say that we shouldn't do this, but we will have to disentangle different serialisations if we want to avoid breaking public keys etc.

my 2 cents: I think it doesn't matter much as long as we agree and document how things are serialized. FWIW I've seen little-endian being used in other places in crypto: https://datatracker.ietf.org/doc/html/rfc8032#section-3.1

@mrmr1993 - approach (3) is not proposing the change the serialization.  It's proposing to leave it whatever it is currently (little-endian), but to make sure to call the serialization method to explicitly put it in little-endian format.  The result should be that for existing litttle-endian machines it stays in the same order and that for big-endian machines it's put into little-endian order, which is the issue to be fixed.


vscode.d.ts missing "interval" TextEditorLineNumbersStyle

https://github.com/microsoft/vscode/blob/c0d41ffbf2bf3b308656632a07fd4505a836817c/src/vs/vscode.d.ts#L621 does not have TextEditorLineNumbersStyle.Interval
This means that extensions cannot use it without tsc complaining and as a result it also does not show on https://code.visualstudio.com/api/references/vscode-api

Related: 198787


The docs are poisoned with html escapes

I wanted to open a PR fixing & on one of the pages (https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocreatefile), but find out there are bunch html escapes all over the place.

Thanks, @Kojoley. We became aware of these -- and the extent of the problem -- this week. I am working through some of them, and we're working on solutions for a couple of special, special cases.  I'll leave this open to track this in our reference repo.

Thanks for the sharp eye @Kojoley. I just pushed fixes for ampersand and greater than/less than, across the DDI docs.  Changes should be visible within an hour or two.  Sorry for taking so long!


large composite key table

Discussed in https://github.com/SeaQL/sea-orm/discussions/1293

Originally posted by meowser December  9, 2022
I have a table I am working with which has a very large composite primary key. When I auto-generate a model using sea-orm-cli the created model causes the following error:
the trait `ValueType` is not implemented for `(std::string::String, std::string::String, std::string::String, std::string::String, std::string::String, std::string::String, std::string::String)

Here is an example of the model:
use sea_orm::entity::prelude::*;

#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Eq)]
#[sea_orm(table_name = "example")]
pub struct Model {
    #[sea_orm(primary_key, auto_increment = false)]
    pub a: String,
    #[sea_orm(primary_key, auto_increment = false)]
    pub b: String,
    #[sea_orm(primary_key, auto_increment = false)]
    pub c: String,
    #[sea_orm(primary_key, auto_increment = false)]
    pub d: String,
    #[sea_orm(primary_key, auto_increment = false)]
    pub e: String,
    #[sea_orm(primary_key, auto_increment = false)]
    pub f: String,
    #[sea_orm(primary_key, auto_increment = false)]
    pub g: String,
    pub h: String,
}

#[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
pub enum Relation {}

impl ActiveModelBehavior for ActiveModel {}

I notice if I take out one of the primary key attributes my code will compile, so I believe there is an six column primary key limit. I was wondering what would be the best approach for dealing with tables like this since I have quite a few tables with long composite keys, which I cannot change?

Hey @meowser, thanks for asking! Yes, the hard limit is 6 composite primary key.
https://github.com/SeaQL/sea-query/blob/83f548472894453afa6c8a5ab780a376a10bc710/src/value.rs#L246-L254
As a temporary solution, you can pick up to 6 columns to be the composite primary key. And leave other as ordinary columns.
I'll create a PR to bump the limit up to 10 this afternoon. Then, you can point your sea-orm to a git dependency if you don't mind.

Somewhat related: https://github.com/SeaQL/sea-orm/issues/1182

Hey @meowser, thanks for asking! Yes, the hard limit is 6 composite primary key.
https://github.com/SeaQL/sea-query/blob/83f548472894453afa6c8a5ab780a376a10bc710/src/value.rs#L246-L254
As a temporary solution, you can pick up to 6 columns to be the composite primary key. And leave other as ordinary columns.
I'll create a PR to bump the limit up to 10 this afternoon. Then, you can point your sea-orm to a git dependency if you don't mind.

thanks!

Hey @tyt2y3, I want your opinion on this.
Currently, we have two similar list constructed in Enum:

sea_query::ValueTuple
sea_orm::Identity

The Dataflow

Input: tuple i.e. (a, b, c)
Storage: Enum with various size represented in Enum variants
Retrieval: tuple or Vec

The Concern
As the size of tuple increased, the Enum implementation waste more memory space. Because the memory size of a Enum is determined by its largest variant.
pub enum ValueTuple {
    One(Value),
    Two(Value, Value),
    Three(Value, Value, Value),
    Four(Value, Value, Value, Value),
    Five(Value, Value, Value, Value, Value),
    Six(Value, Value, Value, Value, Value, Value),
    Seven(Value, Value, Value, Value, Value, Value, Value),
    Eight(Value, Value, Value, Value, Value, Value, Value, Value),
    Nine(Value, Value, Value, Value, Value, Value, Value, Value, Value),
    Ten(Value, Value, Value, Value, Value, Value, Value, Value, Value, Value),
}

The memory needed to store ValueTuple::One is the same as ValueTuple::Ten.
The Proposal
We can swap the storage from Enum to Vec, this will greatly reduce memory waste. The conversion methods will be kept but to convert input tuple into Vec instead of Enum. We can still check the arity by calling Vec::len().
However, it will open a hole where an empty Vec is a potential. But I think normal user who instantiate through tuple won't fall into this.

Just a random thought: is it possible to add feature configurations to enum variants? Such that 7-10 is only compiled conditionally if you ask for it?

Just a random thought: is it possible to add feature configurations to enum variants? Such that 7-10 is only compiled conditionally if you ask for it?

Still, this isn't attacking the fundamental problem of it. And I think it's not a good use of feature hahaa.

True :D

Yeah it started from tuple of three which I think is the ideal size.
I don't want basic usage to be penalized, so potentially it should look like:
enum ValueTuple {
    One(Value),
    Two(Value, Value),
    Three(Value, Value, Value),
    Many(Vec<Value>),
}


epoch instead of step for epoch metrics

What does this PR do?
change epoch lvl metrics to log using epoch instead of steps for x
addresses #3228
Before submitting

[ ] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together? Otherwise, we ask you to create a separate PR for every change.
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

Oh I was only thinking about tensorboard logger, which doesn't let you do much in terms of comparing/overlaying different graphs/metrics.
I don't have much experience with other loggers so yes def still need more input from users of non-tb loggers.

@s-rog maybe a bit patient with implemented new features, till v1.0 we shall be very conservative with adding new things and I am also not very convinced about this API change... 🐰

yeah let’s wait. this is also wrong. it would break all metrics.


2.0.0 requires unstated dependency @types/lodash.flowright

Intended outcome:
Upgrading from 1.x release to the 2.x release.
Actual outcome:
Error at node_modules/react-apollo/browser.d.ts:6:26: Could not find a declaration file for module 'lodash.flowright'. '/Users/x/x/node_modules/lodash.flowright/index.js' implicitly hasan 'any' type.
  Try `npm install @types/lodash.flowright` if it exists or add a new declaration (.d.ts) file containing `declare module 'lodash.flowright';`**How to reproduce the issue:**

Install react apollo in a typescript project and run tsc
Version

<EMAIL_ADDRESS><EMAIL_ADDRESS>

➤ Nhat Khanh commented:
Confirm error

➤ Cory Deppen commented:
It looks like the compiler didn't catch this (and many other instances like it) because the noImplicitAny compiler option isn't being used. Unfortunately, installing @types/lodash.flowright won't resolve it and results in an error [ts] Module<EMAIL_ADDRESS>resolves to a non-module entity and cannot be imported using this construct.
Using the lodash-es package (instead of lodash or lodash.flowright) along with the @types/lodash-es package will allow specific functions to be imported in ES modules and compile without error when the noImplicitAny compiler option is used.

import * as compose from 'lodash.flowright';
export { compose };

import flowRight from 'lodash-es/flowRight';
export { flowRight as compose };If there is agreement on this approach, I don't mind working on a PR.

➤ Inaki Anduaga commented:
Same error here. The Typescript type definition errors are kinda ruining the fun of experimenting  with an apollo integration

➤ Eitan Yarmush commented:
Just encountered this same error and used the above fix in my node_modules. Have you started a PR for this? @corydeppen

➤ Cory Deppen commented:
Not yet. I wanted to see if there was agreement on the approach first, but haven't heard anything yet.

➤ Jurosh commented:
@inakianduaga it's kinda is. Hope this will be resolved soon. For now probably best to downgrade to 1.4.16 where typings are just fine. Migration back to v2 should be quite straightforward later as looks like there aren't really many breaking changes.

Seems a few issues I've seen recently have been modified to show @jbaxleyiii submitted them all and included "[user] commented:" lines. I can't tell if this was intentional or not and it's a bit unusual. In some cases, they've been closed but I can't determine why and whether a PR has already been submitted and/or merged. Using this issue as an example, why was it closed and will the issue be resolved elsewhere?


Update text -- we do support PDF uploads now

Wonderful!
Actually, the original version is correct here -- to simplify the onboarding process for a project, this is now PDF-only. We still have the image functionality, but I don't believe it's hooked up right now.

Oh sorry for the confusion then :)
(BTW, not for mentioning on the website, but just mentioning it here for future reference: if someone has a bunch of images, then https://github.com/josch/img2pdf is a good way of turning them into a PDF.)

@akprasad updated.


Fixed path searching behavior in DBiT reader.

With this update we change the behavior of the DBiT reader in paths selection and prioritization.
Specifically, the argument path of the function spatialdata-io.readers.dbit.dbit() is now optional.
If paths to files are given with the specific arguments anndata_path, barcode_position or image_path, these are selected, while matching files in the path directory are ignored.
In the old behavior, the matching files in the path directory were prioritized, leading to ambiguities when a file path was given, and when multiple pattern matching files were found in the path directory.
Major changes

The file path anndata_path, barcode_position or image_path is now always selected if given.
An Error is now raised if multiple matching files are found in path.

Hi, thanks for the update! I left a comment; when it is addressed we are good to merge 😊

Hi! Thanks for your suggestion! :smile:
Other than the fix you suggested, I have fixed _check_path(), that was giving an error raised when path = None and path_specific = None and optional_arg = True, practically ignoring the fact that the file to find was optional.

Thanks for the edits and the updates. I have made some minor code changes, approving now 😊

Thanks for you corrections and for the support! :smiley:


[FLOC-1465] Dataset deletion endpoint

https://clusterhq.atlassian.net/browse/FLOC-1465

Thanks @itamarst
This all looks good, please proceed.
A couple of questions:

When does a deleted dataset get removed from the configuration?
What will be the API response if I attempt to delete a deleted dataset? I imagine that it should be the same as if I attempt to delete an unknown dataset.

Consider adding an extra example to demonstrate that behaviour. (idempotent or 404 behaviour)

Not clear how deleted dataset gets removed from configuration. It'd be nice to have, but not essential to the feature, so for now we're not prioritizing AFAIK.
Idempotent, yeah. An example... might be a little weird given our current example setup which is a single request/response per example? I will definitely make sure to document it in the prose.

Thanks @itamarst
This makes sense.
I'm still not sure about the idempotent DELETE behaviour. I left some comments about that above, in particular about what should happen if I attempt to update a deleted dataset.
There were a few typos.
The PR diff seems to contain changes from various other branches, probably just because it needs merging forward.
DELETE API examples contain some request bodies, which seems wrong.
There's missing coverage of the IndexError when there are no primary manifestations, but I think we deliberately removed the test for that behaviour in the UPDATE datasets API branch.

http://build.clusterhq.com/results/complete-coverage/delete-dataset-API-FLOC-1465/flocker_control_httpapi.html#n237

...so I guess it can wait until we do https://clusterhq.atlassian.net/browse/FLOC-1403
Answer or address those points, file followup issues then merge, or put it back up for review if you decide to change the DELETE deleted datasets behaviour.

Thanks! Definitely something weird about the diff...


Goaccess gives IPv4/6 is required.

Hello, i am very new to using GoAccess and have run into a little bit of an issue.
==483732== FILE: /root/goaccess/access_log
==483732== Parsed 10 lines producing the following errors:
==483732==
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732== IPv4/6 is required.
==483732==
==483732== Format Errors - Verify your log/date/time format
My goaccess.conf:
time-format %H:%M:%S
date-format %d/%b/%Y
log-format "%h %A:%p,%V>%v %u [%{%Y-%m-%d %H:%M:%S}t.%{msec_frac}t %{%z}t] "%r" %>s %b "REFERER=%{Referer}i" "%{User-agent}i" us=%D connstat=%X respB=%B inB=%I outB=%O [pid %P:tid %{tid}P] errid=%L uid=%{UNIQUE_ID}e"
access.log
<IP_ADDRESS> XXX.XX.XXX.XXX:443,ala.opoka.eu>ot2.optilo.eu - [2022-08-23 10:54:19.786 +0200] "GET /opt_ext_w1dxfa/pd/druid.php?m=zamowienie&s=OrderTransportStatusChange&key=id_zam_zamowienie,918990,status_operacyjny,100 HTTP/1.1" 200 66479 "REFERER=https://ola.polka.com?m=zamowienie&s=ZamowienieTransportPliki&key=id_zam_zienie,918990" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.81 Safari/537.36 Edg/104.0.1293.54" us=96054 connstat=+ respB=66479 inB=1411 outB=67720 [pid 1535151:tid<PHONE_NUMBER>09152] errid=- uid=YwSVu2Pv@n6Kcet-ISmCBgAAAII
Pleas help me.

This should do it:
goaccess access.log --log-format='%^ %h:%^,%v %^[%d %t.%^] "%r" %s %b "%^=%R" "%u" us=%D %^' --date-format='%Y-%m-%d' --time-format=%T

Thanks for the answer already resolved.
Solution.
log-format %h %^:%^,%^>%^ %^ %^[%d %t.%^ %^] "%r" %D %s %b "%R" "%u"

Closing this. Feel free to reopen it as needed.


Narrator does not read the state as ‘Expanded/Collapsed’ of "Variable options" button

A team member will update this issue with more details soon.

This is your friendly Microsoft Issue Bot. I created this issue automatically as requested by a team member.


Question: Is multiprocessing process spawn mode supported on Linux when using standalone or onefile

Nuitka Version: <IP_ADDRESS> and "Develop" as of 27/08/21.
OS: Ubuntu 20.04 64 Bit
Python: 3.9.4
Installation:  via pip in a virtualenv, from python compiled from source

I'm trying to compile an application which makes use of multiprocessing in spawn mode.
A minimal example such as the following doesn't work ("Hello" is never printed):
import multiprocessing as mp

def f(name):
    print("hello", name)

if __name__ == "__main__":
    ctx = mp.get_context("spawn")
    p = ctx.Process(target=f, args=("test",))
    p.start()
    p.join()

Built with:
python3 -m nuitka\
  --quiet\
  --onefile\
  --assume-yes-for-downloads\
  --output-dir=output\
  src/test.py

The documentation from the multiprocessing module, implies that this may not work with Nuitka though:

https://docs.python.org/3/library/multiprocessing.html
Warning The 'spawn' and 'forkserver' start methods cannot currently be used with “frozen” executables (i.e., binaries produced by packages like PyInstaller and cx_Freeze) on Unix.
The 'fork' start method does work.

It would be great even to get just a confirmation that this isn't supposed to work rather than wondering if it's a bug.
Purely for my own curiousity, any pointers towards what is stopping it from working or making this difficult to support would be interesting too!

The multiprocessing plugin makes it work on Windows. It's hard coding things in 2 places for win32, you would have to lift that.
But the question is why, this is an inferior mode of operation, is it not? Using threads on Linux will be much faster.
Yours,
Kay

Thanks - that's helpful just knowing that.
Having two parts of the program being more isolated compared to using forking or using threading is beneficial for this particular application.

yup, so it's doable, seems this might apply for you: https://nuitka.net/pages/commercial.html I guess I can make it work in one day, get in touch via the form if you are interested.

I have come across issues with multiprocessing.manager on macOS, where it seems that this is also used, therefore I have undertaken the effort to implement this, and it's currently on factory. The multiprocessing plugin is no longer limited to Windows, but still has to be activating with --enable-plugin=multiprocessing to add the support. Linux works without it normally, but the plugin makes the example code work.
Code is current on factory, https://nuitka.net/doc/factory.html and needs to be tested before it can be included in a release, but the matter is urgent as it affects commercial macOS users.

Yes, this was also what was missing for macOS to work. It seems it uses shared memory for multiprocessing.manager on Linux, but not on macOS, making it need the resource tracker process, which is also what keeps back spawn mode.

This is part of the 0.6.18 release.


Oxford brca importer update

Added functionality to extract servicereportidentifier from BRCA Germline batches. Coverage test updated to cover this feature, too.

LGTM


Add 'Basin / area' polygon layer with the geometric area of the basin

What
Next to the Point-representation of a Node, I propose to add a Polygon to basins representing the area for:

developing, and parameterizing basins in a new model
re-parameterizing basins in an existing model
providing more context to a basin.Node represented by a point.

Why

As model-developer I want to parameterize a basin with spatial data; shapes/with precipitation, infiltration, etc. For that I need a Polygon-representation of my basin so I can create an overlay to compute basin values.
As a model-developer I want to specify all outlets of the basin of interest. These I typically model at the boundary of the basin-polygon
As model-developer I want to re-parameterize an existing-model (similar to 1). For that I need a still existing Polygon of my basin. This can only be guaranteed if it is stored in the model database.
As a modeller I want to validate my model inputs; e.g. A(h) curves can not exceed A > Polygon.area. I typically check if my basin.areas sum up to the total topographical area to be modelled (e.g. Ribasim-NL ~ total area of NL).
As a hydrologist/end-user I want to be able to see the area on a map when clicking as it explicitly defines the basin on a map (more context). The network (Point-representation) still tells me how the basin is related to other basins

How
Current thoughts:

add Basin.area parameter with a Polygon GeoSeries
parameter could be optional, but I suggest to define that in the toml, e.g. basin_area = true
if basin_area = true all basins should have a polygon assigned to it, if not I would expect a validation-error.
In database.gpkg I would suspect a layer Basin / area
Cherry on cake; enhance qgis plugin by showing polygon when node is selected

One thing to mention: in many coupled models we expect to make a distinction between different river or drainage system within a single hydrological area. We've mostly been speaking in LHM terms, in the sense of primary, secondary and tertiary systems, generally linked together.
That shouldn't create any problems, as in case of (primary, secondary, tertiary) the same polygon just happens to be repeated three times. (Ideally, then, the basin nodes representing the T -> S -> P graph for a single area would be spaced out a little bit, but still located within the polygon.)

One thing to mention: in many coupled models we expect to make a distinction between different river or drainage system within a single hydrological area. We've mostly been speaking in LHM terms, in the sense of primary, secondary and tertiary systems, generally linked together.
That shouldn't create any problems, as in case of (primary, secondary, tertiary) the same polygon just happens to be repeated three times. (Ideally, then, the basin nodes representing the T -> S -> P graph for a single area would be spaced out a little bit, but still located within the polygon.)

Goed point. As an alternative we can create a (optional) catchment-layer that can be referenced by one or more basins?

Ugh last week I wrote quite a long comment here, but coming back I see it never got posted.
With a few lines of Python (see below) you can add other tables to the database. The main problems with it are:

It is not standardized or supported by Ribasim so it only becomes some kind of convention, which is not great for interoperability
The Ribasim QGIS plugin currently errors on extra tables
Ribasim Python and the core both ignore extra tables

We could support extra columns by adding the meta_ prefix. I suppose we could come up with something similar for extra tables. The GeoPackage spec does not support adding a second geometry column. This doesn't help the interop though.
So far we've completely ignored geometries in the core, to the degree that they are optional. I've never seen a model without geometries, and I feel uneasy about the possibility that the Edge geometry and from_ and to_ mismatch. That could lead to very confusing situations, so I think we should start validating Node and Edge geometries in the core. We could probably just decode the GeoPackage geometry encoding ourselves since we would need very little, and to avoid adding a GDAL dependency.
node = gpd.read_file(modeldir / "database.gpkg", layer="Node")
basin_area = node[node["type"] == "Basin"].geometry.buffer(100.0)
basin_area.to_file(
    modeldir / "database.gpkg", layer="Basin / area", driver="GPKG", index=True
)

For Basin / area in particular we'd first need a good definition. In principle the Basin only corresponds to the water, not the land. Including land leads to prettier polygons though. But even including land, @d2hydro mainly expects a mesh topology without overlap, but @Huite would like overlapping polygons to represent different systems in the same area.
To make matters more complex, to account for every rain droplet falling over the river basin only once, some mesh topology or grid is probably needed, to send it directly to open water (Basin), or some land routine (coupled or not). For the Dutch model we might give MetaSwap that job, though outside I feel like the current Ribasim Basin precipitation is way too error prone for these kinds of issues. A warning recently needed to be added: https://deltares.github.io/Ribasim/core/equations.html#precipitation.
I can't think of much use for polygons for the water areas that the Basin really represents. Perhaps, similarly to #661 where a separate Precipitation node was suggested, we need a separate Land node. This could require a non-overlapping mesh topology or grid, where each land zone maps to one basin, and each basin maps to 1:n zones. So there wouldn't be a Basin / area, but a Land / area, and the primary, secondary and tertiary Basins all map to different zones.
Many things here, some will need separate issues, but I just wanted to put some thoughts out there for discussion.

Some thoughts:

Realistically: edge geometries will be involved with 100% of the models.
The fact that Ribasim doesn't use them internally is almost an implementation detail (?)
Realistically, polygon geometries will also be involved in ~99% of the models.
The output is currently not self-describing at all. If you run a model, but don't store the input along with the output, you have no way of analyzing it.
A big bonus is visualization as well: ideally you can associate your timeseries with a polygon dataset, and have it work with the QGIS Temporal Controller. Not sure how well that currently works.
I don't think we necessarily need to be that strict about the Basin / area definition? The area is just some representative area. In some cases, this can be the water exactly. In most cases, it is just an envelope.
What seems reasonable to me: Ribasim requires this Basin / area with a 1:1 relation with the basin nodes. Unlike the edge geometry, it can just copy them as-is to the output directory in some form (e.g. to a geometry geopackage, containing just nodes, edges, and these geometries as separate tables).
Most importantly, I think the envelope geometries solves both of @d2hydro and my problems.
Accounting for every raindrop is a different problem and probably requires a different concept to begin with. E.g. what if you have a wetland area without clear boundaries between land and water (e.g. is inundated half of the time). You probably want to define a Wetland basin or something, with distinct evaporation for land versus water. In the current scheme, accounting for a droplet falling once it solves in the pre-processing.

A specification:
Let's define the GeoSeries I need for my 'use-case' as non-intersecting-Polygons as defined by Shapely:

@Huite envelope as it has a meaning in GeoPandas (Shapely), and it's not what I mean: https://geopandas.org/en/stable/docs/reference/api/geopandas.GeoSeries.envelope.html
@visr (2D) mesh is not the same as non-overlapping-polygons by definition of MDAL (Lutra Consulting), at least last year.

Keep it as simple as possible:

My stories (see introduction) can simply be fulfilled by having a structure to store (Basin) Polygons coherently with your model project. Not forcing it (yet) but standardizing, so we can write code to utilize them in our own, and others models.
Introducing a manifest-file might offer another solution here? To separate the files/data you need for you julia-core that needs no messing arround (toml, database.gpkg and results), and all meta-data the modeller/user needs to fullfill the user-stories described above.

@d2hydro You're right, I probably shouldn't have used the word envelope, I guess I should've said some kind of bounding polygon.
The non-overlapping part: this doesn't have to be required by Ribasim, right?
You need non-overlapping/non-intersecting parts, the MODFLOW coupling need overlapping parts.
You can assert that the polygons don't intersect, I would just not assert that.
I agree and think we can keep it (as) simple (as possible).

@d2hydro You're right, I probably shouldn't have used the word envelope, I guess I should've said some kind of bounding polygon.
The non-overlapping part: this doesn't have to be required by Ribasim, right? You need non-overlapping/non-intersecting parts, the MODFLOW coupling need overlapping parts. You can assert that the polygons don't intersect, I would just not assert that.
I agree and think we can keep it (as) simple (as possible).

@Huite, you're correct Ribasim doen't have to require/do anything by/with these polygons.


[Nuxt] HMR / Auto-reload

As shown in /examples/nuxt Telefunc supports Nuxt.
But creating a new .telefunc.js file requires the user to stop and restart the Next.js dev server.
We should be able to solve this by doing something like https://github.com/vikejs/telefunc/issues/10#issuecomment-1000105604.
Contact me if you are interested in working on this.

Done.


[mesheryctl] Correct channel command misspelling

Description
➜  ~ mesheryctl system channel -s edge
Successfully setted channel...

"setted" is misspelled.
Expected Behavior
Change phrase to:
Subscribed to [stable | edge] channel.

@JubayerJoy would you like to address this?

@leecalcote, I'd love to, yes.
Thanks.


Remove i18n keys with empty strings

i18n-check

The following components have not been translated
chartkit.menu.inspector (en)chartkit.menu.inspector (ru)component.dialog-share.view (en)component.dialog-share.view (ru)component.relative-dates-picker.view (en)component.relative-dates-picker.view (ru)dash.widget-dialog.edit (en)dash.widget-dialog.edit (ru)editor.grid-scheme-select.view (en)editor.grid-scheme-select.view (ru)main.service-settings.view (en)main.service-settings.view (ru)

Wait for the reviewers to check your changes in Weblate and try running github action again.


Addon crashes when changing scenes (Godot 4 only)

Godot version: 4.0.2
Addon version: 5baf5d86008e2aa9584261e9f518a689a6d488b5
Changing scenes in Godot 4 is currently not quite working. There are two issues that I was able to reproduce in the demo project: https://github.com/utopia-rise/fmod-gdnative/tree/scene-change-crash

Issue 1: changing to a different scene will crash the game silently
After some debugging it seems to happen inside Fmod.update() function. There are no logs as it simply crashes silently. Click the "Change to other scene" button on the branch linked above to reproduce!
Issue 2: reloading the current scene will spam thousands of errors
When unloading and reloading the current scene instead, the game does not crash but thousands of errors are being produced over time.

Click the "Reload current scene" button on the branch linked above to reproduce!

Cannot reproduce with your branch.


More colors

more colored things
some refactoring

Codecov Report

Merging #45 into master will increase coverage by 4.56%.
The diff coverage is 89.95%.

@@             Coverage Diff              @@
##             master      #45      +/-   ##
============================================
+ Coverage     79.96%   84.53%   +4.56%
- Complexity      170      206      +36
============================================
  Files            22       22
  Lines           654      763     +109
  Branches         47       44       -3
============================================
+ Hits            523      645     +122
+ Misses          106      100       -6
+ Partials         25       18       -7

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/app/domain/command/EditCommand.java
62.5% <0%> (-4.17%)
2 <0> (ø)

src/main/java/app/domain/command/NullCommand.java
100% <100%> (+11.11%)
4 <0> (+1)
:arrow_up:

src/main/java/bookmarks/BookBookmark.java
90.9% <100%> (+4.24%)
9 <5> (+3)
:arrow_up:

src/main/java/app/dao/BookMarkDAO.java
79.81% <100%> (+2.23%)
23 <0> (ø)
:arrow_down:

src/main/java/app/io/StubIO.java
100% <100%> (+13.79%)
13 <5> (+3)
:arrow_up:

src/main/java/app/io/IO.java
40% <100%> (+15%)
2 <1> (+1)
:arrow_up:

src/main/java/bookmarks/BlogBookmark.java
96% <100%> (-4%)
9 <5> (+3)

src/main/java/app/domain/Tag.java
46.66% <58.33%> (+7.77%)
10 <5> (+5)
:arrow_up:

src/main/java/app/io/ConsoleIO.java
80% <75%> (+30%)
8 <3> (+5)
:arrow_up:

src/main/java/bookmarks/OtherBookmark.java
80.76% <75%> (-10.14%)
8 <4> (+3)

... and 8 more

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 ee7132b...69db88a. Read the comment docs.


load_balancing: allow to disable shuffling replicas

Pre-review checklist
When token awareness is enabled in the default load balancing policy, it chooses a random replica to send the query to. This is supposed to balance the load however in some scenarios it might be more beneficial to always choose the same replica - for example, reads might benefit from better caching. This PR adds an option to disable this behavior, which will cause the load balancing policy to always choose nodes in the same order for each replica set.
This feature was inspired by similar functionality in the cpp driver.
Fixes: #634

[x] I have split my patch into logically separate commits.
[x] All commit messages clearly explain what they change and why.
[x] I added relevant tests for new features and bug fixes.
[x] All commits compile, pass static checks and pass test.
[x] PR description sums up the changes and reasons why they should be introduced.
[x] I added appropriate Fixes: annotations to PR description.

Accidentally marked as draft, un-drafting.

v2:

Changed the fixed_shuffle_seed size from u32 to u64
Got rid of an unnecessary clone in assert_proper_grouping_in_plans
Added fixed_shuffle_seed to the impl Debug


More detailed CONTRIBUTING.md

It will be great if there was some additional information\documentation for contributors in CONTRIBUTING.md.
E.g. used layouts, code style.

Thanks for the suggestions! I'd be happy to see pull requests about it.


UI Issues #4

Rancher versions: 5/22
**Issues: **

[x]  Error message not designed.

[x] On Container & Scaling Group details pages, the Basic Info at top is not aligned.

[x] "Viewing a Single stack" text in stack detail page, makes no sense.

[x] Logs section in Scaling Group/LB detail page needs to be designed

[x] If I have no links in Scaling Group/LB, the details section for Links needs to be redone

[x] Certificate section in Scaling Group/LB details page, label needs to be changed

[x] Port section in Scaling Group/LB details page, label needs to be changed

[x] Add scaling group, Port Mapping and Environment Variables have different spacing under their labels

Version - 5/25
Verified fixed


Transfer demo/checkpoint to the Microsoft organization

Hello @JeffreyXiang and team 🤗
I'm Niels and work as part of the open-source team at Hugging Face. I discovered your work through AK's daily papers, the paper page is here: https://huggingface.co/papers/2412.01506. The paper page lets people discuss about your paper and lets them find artifacts about it (your models for instance), you can also claim the paper as yours which will show up on your public profile at HF.
I've got some suggestions to improve its discoverability on the hub :)

I've opened a PR to improve the model card: https://huggingface.co/JeffreyXiang/TRELLIS-image-large/discussions/1
I've opened a PR to link the demo to the paper page: https://huggingface.co/spaces/JeffreyXiang/TRELLIS/discussions/2

Besides that, would you be interested in transferring the model and demo to https://huggingface.co/microsoft? This could enhance its visibility, we could add a collection which groups the model, demo and paper page together.
Let me know if you need any help!
Cheers,
Niels

Hi @NielsRogge,
Thank you for your thoughtful suggestions and for taking the time to improve the visibility of our work. We are happy to proceed with merging the PR for text-to-3D trending at this time.
Thanks once again for your assistance!
Best,
Yu

Sure. Let us merge the PR to enable download counts!
For the checkpoint and demo, we'd like to temporarily keep them on our HF profile before considering a transfer to Microsoft at a later time.
Thanks again!


improved docs; updated changelog; new card.mv_samples method;

Codecov Report

Merging #18 (1a8ec20) into main (31ed376) will increase coverage by 0.01%.
The diff coverage is 93.10%.

@@            Coverage Diff             @@
##             main      #18      +/-   ##
==========================================
+ Coverage   94.08%   94.10%   +0.01%
==========================================
  Files           8        8
  Lines         338      339       +1
  Branches       59       59
==========================================
+ Hits          318      319       +1
  Misses         14       14
  Partials        6        6

Impacted Files
Coverage Δ

deluge_card/deluge_card.py
91.91% <92.59%> (-0.09%)
:arrow_down:

deluge_card/__init__.py
100.00% <100.00%> (ø)

deluge_card/deluge_sample.py
98.83% <100.00%> (+1.58%)
: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 31ed376...1a8ec20. Read the comment docs.