Cannot Submit CCL Transactions from Frontend Wallets

I use the CCL to prepare a transaction in my backend, which I send back as a hex string to the frontend for the user to sign and submit using their favorite browser wallet. While there is no problem with the generation, and the signing looks fine, there is an error after the signature for the wallets that I tested (Vesper, Nami, and Eternl).
The error message is:
"{\"contents\":{\"contents\":[\"DecoderErrorDeserialiseFailure \\\"Shelley Tx\\\" (DeserialiseFailure 0 \\\"expected list len or indef\\\")\",\"DecoderErrorDeserialiseFailure \\\"Shelley Tx\\\" (DeserialiseFailure 0 \\\"expected list len or indef\\\")\",\"DecoderErrorDeserialiseFailure \\\"Shelley Tx\\\" (DeserialiseFailure 0 \\\"expected list len or indef\\\")\",\"DecoderErrorDeserialiseFailure \\\"Shelley Tx\\\" (DeserialiseFailure 0 \\\"expected list len or indef\\\")\",\"DecoderErrorDeserialiseFailure \\\"Shelley Tx\\\" (DeserialiseFailure 0 \\\"expected list len or indef\\\")\",\"DecoderErrorDeserialiseFailure \\\"Shelley Tx\\\" (DeserialiseFailure 0 \\\"expected list len or indef\\\")\"],\"tag\":\"TxCmdTxReadError\"},\"tag\":\"TxSubmitFail\"}"

I simplified the transaction as much as possible, but even with this basic transaction, it shows the same behavior:
String sender = "addr_test1qzfw9tj3lvpae32ugu2sdl34hhk6m8pxdvxsns4ch37tg3ghw90ykk35yf6dp56stjk6qjja9342yf4j4d7cgf3453gsz77xa5";
String receiver = "addr_test1qp7dhqxetsqn6d6k6k0kkzek7dgaprvpecu6d0w464f54xmxp8zfncgu2y5ug5ud9t6sgu6fsmqlym2yhyq9l54405sqwynupf";

Tx tx = new Tx()
        .payToAddress(receiver, Amount.ada(5))
        .from(sender);

QuickTxBuilder quickTxBuilder = new QuickTxBuilder(backendService);
Transaction transaction = quickTxBuilder
        .compose(tx)
        .feePayer(sender)
        .withRequiredSigners(paymentCredentialHash.get()) // senders payment credential
        .build();

return transaction.serializeToHex();

My frontend code:
const api = await (window as any).cardano.nami.enable();
// ...
if (response.status === 200) {
  try {
    const preparedTransaction = response.data.preparedTransaction;
    const signedTransaction = await api.signTx(preparedTransaction, true);
    const txId = await api.submitTx(signedTransaction);
  } catch (error) {
    console.error(error);
  }
}

In this case, Nami opens as expected and allows the transaction to be signed, which looks as expected. The issue occurs during submission. I also tried sending the signed transaction back to my backend and submitting it using the CCL, but it results in the same issue.

This is the signed transaction (using different sender and receiver addresses than above)
a10081825820373bc5f0bc56c5cc5c7f96c3251e5c11bfb8a6fcc6abefa4e5c3be6a29d316db5840c4ff15b7af57707f8ef65ede374cfe707705ad180f4db0336ea632356a43c48f77a5916d470545ac323596574becf978083ae57e3f68caacbb104b38c4549905

This is the unsigned transaction
84a900818258204952356ec45df548251b0aea3e6c75c649062f029cb5f9d95cded3c7a7308bb7000182825839001564641507c7fcb96eee86f7fce9b5db19d4fafb2d728465e324524298fbdf5f43d7d000d00353fd7816f5ffc76c7e5dce2d6794fab103251a001e8480825839009a3eea4ce6b74af9e77213f4e94af602588a09fd552afb5113520ff6b83abf370a14870fdfd6ccb35f8b3e62a68e465ed1e096c5a6f5b9d61a002a7358021a0003536805a1581df007d005982b3acac32aee6f6e9d3eb8c897f54bb396255845ca69d5c7000b5820d941a1c0f102b907f0739f58bd77c77aa5877bd907e842724d2cdac392a6c3910d818258204952356ec45df548251b0aea3e6c75c649062f029cb5f9d95cded3c7a7308bb7000e81581c9a3eea4ce6b74af9e77213f4e94af602588a09fd552afb5113520ff610825839009a3eea4ce6b74af9e77213f4e94af602588a09fd552afb5113520ff6b83abf370a14870fdfd6ccb35f8b3e62a68e465ed1e096c5a6f5b9d61a00474e24111a0004fd1ca20581840300d8799f58406135393161366434306266343230343034613031313733336366623762313930643632633635626630626364613332623537623237376439616439663134366540581cb83abf370a14870fdfd6ccb35f8b3e62a68e465ed1e096c5a6f5b9d6427b7dff8219b6831a013300cf06815902c65902c301000032323232323232232322533300532323253330083370e900218049baa00113253330093007300a37540022a66601266e1d2002300a3754601c60166ea80044c8c94ccc02cc8c8cc004004dd6180218079baa00722533301100114a0264a66601e64a66602066ebcc054c058c048dd50009ba65333010300e482024bd00452f5bded8c0264646600200297adef6c60225333016001133017337609801014000374c00697adef6c6013232323253330173375e66018911000024c103d879800013301b33760981014000374c00e00a2a66602e66e3d2210000213301b337609801014000374c00e00626603666ec0dd48011ba600133006006003375660300066eb8c058008c068008c060004c8cc0040052f5bded8c044a66602a00226602c66ec130010140004c01051a001e8480004bd6f7b630099191919299980b19baf3300b4881000024c103d879800013301a337609810140004c01051a001e848000005153330163371e91010000213301a3376098010140004c01051a001e84800000313301a337606ea4008dd4000998030030019bad3017003375c602a0046032004602e002266ebcc018c048dd5180318091baa0014c0122d8799f581c1564641507c7fcb96eee86f7fce9b5db19d4fafb2d728465e3245242ff0014a0602800429444cc00c00c004c050004894ccc034cdc80010008a60103d87980001533300d3371e0040022980103d87a800014c103d87b8000132533300c3001375c6004601c6ea802c4c004dd7180198071baa00b14a0466e212000371a00229408c0400048c03cc040c0400045858c034c028dd50008b18061806801180580098039baa00114984d9594ccc00cc004c010dd500109919191919191919299980718088010a4c2c6e64dd7180780098078011bae300d001300d00237326eb8c02c004c02c008dd7180480098029baa00216370e90002b9a5573aaae7955cfaba05742ae881f5f6

Alternatively, if you can send the full signed tx to the backend, the step to assemble is not required.
The above example is specific to multi-sig use case, where the second signer is maintained in the backend.

Thank you @satran004 the process that you explained works like charm
    public Result<String> submit(String transactionHex, String witnessSetHex) throws CborDeserializationException, CborSerializationException, ApiException {
        BackendService backendService = new KoiosBackendService(Constants.KOIOS_PREPROD_URL);

        TransactionWitnessSet witnessSet = TransactionWitnessSet.deserialize((Map) CborSerializationUtil.deserialize(HexUtil.decodeHexString(witnessSetHex)));
        Transaction transaction = Transaction.deserialize(HexUtil.decodeHexString(transactionHex));
        transaction.getWitnessSet().setVkeyWitnesses(witnessSet.getVkeyWitnesses());

        return backendService.getTransactionService().submitTransaction(transaction.serialize());
    }

I would close this issue now. 😊


Change URLs in Blogs and Events to spawn new tab and replace CEC

This PR does the same URL treatment to the blog and events pages as fixes bad links. Also replaces occurrences of CEC with California Energy Commission in content pages.

I added another commit that fixes old Pierce et. al. 2018 links that 404.

Yay! Sorry it turned into such a mess!


issues with Adafruit ST7789 240x280 display

I'm trying to run this on a raspberry pi zero w 2 with the adafruit rounded TFT display wired in SPI and I'm getting various issues.
Specifically the top 40 or so rows of pixels are just snowy fuzz. Looking into the printed lines of the terminal output I see that the driver assumes that the display is 240 x 240 when it is not. Changing st7735r.h DISPLAY_NATIVE_HEIGHT to 280 seems to have fixed this but I just get a row of snowy fuzz at the top of the screen now. I ran into the same issue with the adafruit Circuitpython library when running the st7789 script there and fixed it by setting the vertical offset to 20 pixels.
I'm also getting 2 columns of noise stretching vertically down the screen. Not sure what that is all about...
Lastly the display seems to be reversed horizontally!
Any help would be greatly appreciated. I know it is possible to fix because I was able to get everything working in python with the circuitpython module, so I'm sure it is just a matter of getting the settings right.

Spencer

Additionally I am having problems shutting my pi down via a shell script since running the driver, which is a bit odd. Haven't been able to nail this one down yet but I believe it is related to this driver because when I try to quit the software via the commandline (ctrl+c) it just says that it received the quit signal and is shutting down but then just stalls out and never quits. sending a kill command does the same.

Adjusting the MADCTL register helps to flip the display horizontally.
Also I recall there may be some kind of offset in how the display controller reads the memory depending on MADCTL register values. E.g. if the height is 280 pixels, it could be that the pixels for those rows are located on memory rows [40, 319] instead of rows [0, 279]. Try adjusting this offset register: https://github.com/juj/fbcp-ili9341/blob/4aa3b97f4d295e3301651bd3dc3d314b25f2531e/st7735r.cpp#L95

I have also seen the inability to shut down cleanly in some cases, not sure what causes that, I did not get to the bottom of it.

Thanks for the reply, I'll try it out. What is the MADCTL register?

MADCTL is
https://github.com/juj/fbcp-ili9341/blob/4aa3b97f4d295e3301651bd3dc3d314b25f2531e/st7735r.cpp#L42-L69

Sorry but I'm struggling a bit with the cpp syntax, I'm a python guy... I understand I need to adjust line 95 but I'm not sure what "0x37" means (hard to google that one...). Or is it arguments 2 and 3 I need to adjust? What you're saying about the vertical register being offset due to the different screen size makes sense.
And in terms of flipping the columns I see at line 45 you define a column address order swap flag. I assume this is what I need to adjust to flip my columns, but again I'm not sure what the (1<<6) syntax is all about...
Sorry for my ignorance of C here! Python is so much easier to read...

Spencer

Ok figured out how to shift the bits to swap the screen! Last bug is a bit more nebulous... which is that the screen seems to freeze after a few seconds. I saw the note in the readme.md to disable DMA and increase the SPI bus divisor, neither of which seem to have fixed it. I assume this is related to the quitting issue because it seems to be that when the screen freezes it does not want to quit gracefully.

If there are two fbcp-ili9341 processes running, then that is certainly an issue and will cause a crash. There should be only one.
However that one fbcp-ili9341 process will spawn a child thread, but that is a thread in the same process, not a new process. The thread will have the same user as the main thread (threads in same process cannot run under different user auth).
Maybe there's a startup script that is spawning fbcp-ili9341 already as root?

I created an rc.local script exactly as you suggested, but if I kill both processes and then CD into the build directory and "sudo ./fbcp-ili9341" I get the same 2 processes when I check "ps aux". I am very new to linux so it is totally possible I'm misunderstanding something about the ps command, but I definitely see two processes with different PID's and need to kill them both individually.

Ok I figured it out! Whenever the display is inactive for a few seconds it crashes, presumably when it goes to "sleep".  Disabling SAVE_BATTERY_BY_SLEEPING_WHEN_IDLE improved CPU load and I've been running for a few minutes now with no crashes, so that seems to do the trick.
Scratch what I was saying about the 2 processes, I'm new to linux and didn't fully understand the process status command - it was actually just the one process.
So what's the issue with sleeping? Is there something I can look into to find the bug, and is it worth fixing? I'm not super concerned with battery life and I can live with the 15% CPU load it currently draws, but if this is something fixable I'd like to fix it.

I have the same display and don't have the crashing issue.
It appears internally it's a 320 x 240 display.
Someone kindly posted some mods to fix the offset here.
https://github.com/juj/fbcp-ili9341/issues/298

Even better, set this:
#if defined(ST7789) || defined(ST7789VW)
#define DISPLAY_NATIVE_WIDTH 240
#define DISPLAY_NATIVE_HEIGHT 300
#define DISPLAY_NATIVE_COVERED_TOP_SIDE 20


Mason fails to resolve JDTLS version for older milestones

:MasonInstall<EMAIL_ADDRESS>fails with  Failed to download file : https://download.eclipse.org/jdtls/milestones/1.26.0/jdt-language-server-1.26.0-202309281329.
The actual version published is :  https://www.eclipse.org/downloads/download.php?file=/jdtls/milestones/1.26.0/jdt-language-server-1.26.0-202307271613.tar.gz
The suffix -202309281329 matches latest jdtls version (1.28.0) https://www.eclipse.org/downloads/download.php?file=/jdtls/milestones/1.28.0/jdt-language-server-1.28.0-202309281329.tar.gz
I believe this happens as the suffix is hardcoded : https://github.com/mason-org/mason-registry/commit/80bd37edc0c919914b80c9421be7c3199ddebaa4
Might be somewhat related to this : https://github.com/williamboman/mason.nvim/discussions/286

Following the purl specs I wonder if we could add the required timestamp a qualifier to the package id:
id: pkg:generic/eclipse/eclipse.jdt.ls@v1.34.0?timestamp=202404031240
This should make it easy to reference it in the source.file.download section.
Alternatively we could append it to the version separated with a dash:
id<EMAIL_ADDRESS>Then split it with an expression to create the final download URL.

you can use :MasonInstall<EMAIL_ADDRESS>to get the next version going since 1.37.0 is also broken

I have created a custom workflow to re-package jdtls without timestamps. You can add the custom mason registry from nvim-java if you want to use it right now.
https://github.com/nvim-java/release-jdtls


Add demoDevice for MAX32xxx microcontrollers

Add demoDevice project running on Analog Devices Inc. MAX32xxx MCUs. Passes all the tests under test/running_canopen.

Kind reminder. @CANopenNode

Sorry, I just missed your PR. Thank you for contributing.

Also add a note at https://github.com/CANopenNode/CANopenNode/tree/master#related-projects

I missed that. Thank you.


[STREAM-146] - Updated logging for new JSON-RPC commands.

Same question as with the streaming-client PR, should we not also update the logging for other commands like retracts/rejects/etc?

It would be nice if the audio and video device components told you if you haven't provided permissions yet, or if permissions were denied. I think those things are on the media state.


Update Readwn.com & Novelmt.com

Source information
Readwn.com & Novelmt.com
Steps to reproduce

Go to Readwn.com or Novelmt.com.
Search any novel on the search bar

Expected behavior
This should show the searched novel if available.
Actual behavior
It is doing nothing but displaying the home page of the website
LNReader version
1.1.12
Android version
Android 11
Other details
Readwn.com & Novelmt.com has changed their domain name and Also their is no difference between Home Page and Latest Page in the Source. On the website of Readwn.com & Novelmt.com there are the tabs Popular, New, & Updates so Use Popular Tab as Home Page for the source and use Updates for Latest Page or you can add These three Tabs in Filters
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 1.1.12.
[X] I have updated all installed extensions.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

Readwn.com & Novelmt.com are now redirecting to Wuxia Fox and Wuxia Fox already has a source in beta
LNReader/lnreader/releases/v2.0.0-beta.0
make sure to convert your backup

Done


Bug fixes

@sumantshiv,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Cannot mousemove on canvas element in Firefox 51

I have a code to mouse move on canvas:
    let canvas = element(by.id(`canvas`)).getWebElement();
    return browser.actions()
      .mouseMove(canvas, {x: 100, y: 100})
      .mouseDown()
      .mouseMove(canvas,  {x: 200, y: 350})
      .mouseUp()
      .perform();

But have issue:
Failed: POST /session/3bfcfe08-4464-4ac4-8dfb-bb7bd87e955e/moveto did not match a known command
      at WebDriverError (D:\e2e\node_modules\selenium-webdriver\lib\error.js:27:5)
      at UnknownCommandError (D:\e2e\node_modules\selenium-webdriver\lib\error.js:296:5)
      at Object.throwDecodedError (D:\e2e\node_modules\selenium-webdriver\lib\error.js:477:11)
      at parseHttpResponse (D:\e2e\node_modules\selenium-webdriver\lib\http.js:499:15)
      at doSend.then.response (D:\e2e\node_modules\selenium-webdriver\lib\http.js:440:13)
      at process._tickCallback (internal/process/next_tick.js:103:7)
  From: Task: mouseMove
      at Driver.schedule (D:\e2e\node_modules\selenium-webdriver\lib\webdriver.js:816:17)
      at actions.map.action (D:\e2e\node_modules\selenium-webdriver\lib\actions.js:124:23)
      at Array.map (native)
      at D:\e2e\node_modules\selenium-webdriver\lib\actions.js:123:29
      at TaskQueue.execute_ (D:\e2e\node_modules\selenium-webdriver\lib\promise.js:2970:14)
      at TaskQueue.executeNext_ (D:\e2e\node_modules\selenium-webdriver\lib\promise.js:2953:27)
      at asyncRun (D:\e2e\node_modules\selenium-webdriver\lib\promise.js:2813:27)
      at D:\e2e\node_modules\selenium-webdriver\lib\promise.js:676:7
      at process._tickCallback (internal/process/next_tick.js:103:7)
  From: Task: ActionSequence.perform
      at ActionSequence.perform (D:\e2e\node_modules\selenium-webdriver\lib\actions.js:122:33)

Bug report

Node Version: v6.9.5
Protractor Version: 5.1.1
Browser(s): Firefox 51
Operating System and Version Windown 10 64 bit
Your protractor configuration file

  browserName: 'firefox',
    marionette: true,
directConnect: true,

The same issue with safari 10.

Not quite sure that driver devs finished this.
See 	/session/{sessionId}/actions in this table
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/WebDriver/status
moveto is specified in w3c draft, but seems like not yet works. It is partially complete.
Looks like 3rd party bug with gekkodriver

Thanks for tracking that down @Xotabu4 I think you are right.
@tamvo94 this sounds like a great fit for a gecko driver issue. Would you be up for opening one in the geckodriver queue?

Thank @Xotabu4 and @NickTomlin
I posted this issue to  geckodriver queue issue

Hmm, seems like this is more of an issue with selenium itself. If you are up for it, could you open an issue there?
I think I'm going to go ahead and close this for now since there's nothing we can do. Thanks!


[WIP] Implement Fluentd Reporter plugin

Implemented Fluentd Reporter plugin based on #984
Requirements
Jackson update in embulk-core is required.
https://github.com/embulk/embulk/blob/master/embulk-core/build.gradle#L43-L48
Fluency 1.7.0 is using Jackson 2.7.1 but embulk-core is using 2.6.7.
I couldn't run without updating Jackson.

I'm going to implement as standalone plugin.
Close this issue.


fix retarded versioning system

kaff pls

okkk

GOD DAMMIT
major.minor.hotfix
1.2.3
1.4.0

OK FINE

i'll make a bot to do it...eventually

actually i didnt mean to reopen this lol. but ok


[CL Message Audit] MsgSwapExactAmountIn

Closes: all testing-related issues & minor bugs for MsgSwapExactAmountIn on internal review board
Clickup: https://app.clickup.com/37420681/v/dc/13nzm9-19320/13nzm9-35420
Brief Changelog

Docs improvements on confusing parts of the message flow
Tests for untested functions (and additional cases for some tested ones):

#5094
#5095
#5096
#5097
#5098
#5099
#5100
#5101

Two rounding-related changes: rounding swap fees up for OSMO-routed swaps and rounding fee distributions down in general:

#5121
#5122

Bug fix for CL gauges not being noticed by checks in pool incentives module (was leading to CL pools not counting towards OSMO-routing fee discount):

#5112

Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior changes? (no)
Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? (no)
How is the feature or change documented? (not documented)

@p0mvn, @czarcas7ic  resolved all your feedbacks


npm not showing 1.1.0 instead of 1.1.1

See https://www.npmjs.com/package/electron-prebuilt.

Seems to be released now


Fix RSpec/ExampleLength errors for heredoc

Overview
Hello. :wave: With the recent upgrade to RuboCop 1.54.0, I'm experiencing errors with heredoc usage within spec examples. This appears to effect any spec that uses heredoc. The errors I'm getting are:
An error occurred while RSpec/ExampleLength cop was inspecting spec/lib/gitt/commands/log_spec.rb:75:4.
An error occurred while RSpec/ExampleLength cop was inspecting spec/lib/sod/graph/node_spec.rb:275:4.

Steps to Recreate
Here's a few examples, I've seen where this is cropping up:
Simply using a heredoc within the body of your it block will cause this error:
it "answers commit with comments" do
  message = <<~CONTENT
    Added test
    # One.
    # Two.
    # Three.
  CONTENT

  expect(commit.message).to eq(message)
end

Alternatively, using a heredoc as your proof will also cause this failure:
it "answers commit with comments" do
  expect(commit.message).to eq(<<~CONTENT)
    Added test
    # One.
    # Two.
    # Three.
  CONTENT
end

Environment
Ruby:  ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [arm64-darwin22.4.0]
RuboCop
1.54.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.29.0, running on ruby 3.2.2) [arm64-darwin22.4.0]
  - rubocop-capybara 2.18.0
  - rubocop-factory_bot 2.23.1
  - rubocop-packaging 0.5.2
  - rubocop-performance 1.18.0
  - rubocop-rake 0.6.0
  - rubocop-rspec 2.22.0
  - rubocop-thread_safety 0.5.1

Thank you for your report! I could not reproduce this.Can you also provide the .rubocop.yml settings?

Hey Yudai, thanks. Yep, here's the full dump from bundle exec rubocop -d:

Debug Dump

bundle exec rubocop -d spec/lib/sod/graph/node_spec.rb

For /Users/bkuhlmann/Engineering/OSS/sod: configuration from /Users/bkuhlmann/Engineering/OSS/sod/.rubocop.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/all.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/ruby.yml
Default configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/config/default.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/capybara.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-capybara-2.18.0/config/default.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-capybara-2.18.0/lib/../config/default.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/factory_bot.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-factory_bot-2.23.1/config/default.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-factory_bot-2.23.1/lib/../config/default.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/packaging.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-packaging-0.5.2/config/default.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-packaging-0.5.2/config/default.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/performance.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-performance-1.18.0/config/default.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-performance-1.18.0/config/default.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/thread.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-thread_safety-0.5.1/config/default.yml
configuration from #{path}
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/rake.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-rake-0.6.0/config/default.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-rake-0.6.0/config/default.yml
Inheriting configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/caliber-0.36.0/config/rspec.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-rspec-2.22.0/config/default.yml
configuration from /Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-rspec-2.22.0/config/default.yml
Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /Users/bkuhlmann/Engineering/OSS/sod/spec/lib/sod/graph/node_spec.rb
An error occurred while RSpec/ExampleLength cop was inspecting /Users/bkuhlmann/Engineering/OSS/sod/spec/lib/sod/graph/node_spec.rb:275:4.
undefined method `last_line' for nil:NilClass
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/parser-<IP_ADDRESS>/lib/parser/source/map.rb:118:in `last_line'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node.rb:266:in `last_line'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:199:in `block in source_from_node_with_heredoc'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:111:in `block in visit_descendants'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `visit_descendants'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:112:in `block in visit_descendants'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `visit_descendants'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:112:in `block in visit_descendants'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `visit_descendants'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:63:in `each_descendant'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:192:in `source_from_node_with_heredoc'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:77:in `code_length'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:25:in `calculate'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/mixin/code_length.rb:36:in `check_code_length'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-rspec-2.22.0/lib/rubocop/cop/rspec/example_length.rb:59:in `on_block'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:107:in `public_send'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:107:in `block (2 levels) in trigger_responding_cops'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:171:in `with_cop_error_handling'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:106:in `block in trigger_responding_cops'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:105:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:105:in `trigger_responding_cops'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:69:in `on_block'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:158:in `on_block'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_block'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:158:in `on_block'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_block'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:20:in `walk'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:87:in `investigate'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/team.rb:156:in `investigate_partial'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/team.rb:98:in `investigate'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:345:in `block in inspect_file'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:344:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:344:in `flat_map'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:344:in `inspect_file'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:287:in `block in do_inspection_loop'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:321:in `block in iterate_until_no_changes'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:314:in `loop'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:314:in `iterate_until_no_changes'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:283:in `do_inspection_loop'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:164:in `block in file_offenses'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:189:in `file_offense_cache'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:163:in `file_offenses'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:154:in `process_file'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:135:in `block in each_inspected_file'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:134:in `each'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:134:in `reduce'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:134:in `each_inspected_file'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:120:in `inspect_files'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:73:in `run'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command.rb:11:in `run'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/environment.rb:18:in `run'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:118:in `run_command'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:125:in `execute_runners'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:51:in `block in run'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:77:in `profile_if_needed'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:43:in `run'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/exe/rubocop:19:in `block in <top (required)>'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/3.2.0/benchmark.rb:311:in `realtime'
/Users/bkuhlmann/.cache/frum/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/exe/rubocop:19:in `<top (required)>'
/Users/bkuhlmann/Engineering/OSS/sod/bin/rubocop:6:in `load'
/Users/bkuhlmann/Engineering/OSS/sod/bin/rubocop:6:in `<main>'
.

1 file inspected, no offenses detected

1 error occurred:
An error occurred while RSpec/ExampleLength cop was inspecting /Users/bkuhlmann/Engineering/OSS/sod/spec/lib/sod/graph/node_spec.rb:275:4.
Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
https://github.com/rubocop/rubocop/issues

Mention the following information in the issue report:
1.54.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.29.0, running on ruby 3.2.2) [arm64-darwin22.4.0]
Finished in 0.6041079999413341 seconds

Additionally, here's my RuboCop configuration. By the way, the Ruby configuration is one of multiple configurations as provided by my Caliber gem so if you need the full list, you can find it here in case that helps too.

Mentioned issue is fixed in RuboCop.
I've checked via gem 'rubocop', github: 'rubocop/rubocop' — no RSpec/ExampleLength errors.
I think we can close this issue because it's kind of third-party and wait for a new (patch?) release of RuboCop.

@AlexWayfer Thank you for confirming this.
@bkuhlmann, could you confirm that this issue has been resolved after release or using a modified version of RuboCop?

Yudai: Confirmed, using the patched version of RuboCop (i.e. using RuboCop via the master branch instead of 1.54.0) all of my above errors go away across multiple projects. Thanks!
Alexander: Thanks for the extra help on this.
I'm going to close this issue. Looking forward to the next patch release!

:information_source: Closing. Will wait for patch release.

RuboCop 1.54.1 with the fix (I believe) has been released.


GridFS example

I couldn't find an example of GridFS integration and I spent some time making it work correctly. Just thought it could be useful for someone else, so I created a PR that adds example to docs.
It would be also great to add link to this example to wiki.
By the way, is it planned to add something like onAfterRemove hook? I also tried to use onBeforeRemove instead of rewriting remove method but it doesn't fire for some reason. But having onAfterRemove hook, that has access to removed documents would be even better. :smile:

Hi @epaminond ,
every .remove() method has a callback. Why this doesn't work for you?
Thank you for PR, I'll add to wiki after testing

every .remove() method has a callback. Why this doesn't work for you?

@dr-dimitru, it does, but inside callback I only get number of removed documents. I mean it would be more convenient to have at least their _id's or even content inside hook.

Sure, I'll add it to v1.6.0

Implemente in https://github.com/VeliovGroup/Meteor-Files/commit/696671a2a67e9cef4d1d06d067be3aef526d6910
Could you please test it from dev branch on your end?

@dr-dimitru, tested it and updated example in PR to use onAfterRemove hook. Thanks for quick response.
I got an error in client console on dev branch, but this seems to be irrelevant to the topic:
files.coffee:501 Uncaught TypeError: Accounts.onLogout is not a function

@epaminond Thank you.
This bug also appeared in this thread see last 3 messages. But, I can't reproduce it. Any help will be appreciated.

OK, I'll check it later today.

Here's my .meteor/packages:
# Meteor packages used by this project one per line.
# Check this file (and the other files in this directory) into your repository.
#
# 'meteor add' and 'meteor remove' will edit this file for you
# but you can also edit it by hand.

# meteor libraries
meteor-base
ecmascript
es5-shim
check
tracker
reactive-dict
email
# standard libraries
jquery
underscore

# ui
static-html
react-meteor-data

# data
mongo
aldeed:simple-schema
aldeed:collection2
dburles:collection-helpers
mdg:validated-method
random
meteorhacks:aggregate

# routing
kadira:flow-router

# i18n
tap:i18n

# time and dates
momentjs:moment

# accounts
accounts-password
accounts-facebook
accounts-google
service-configuration

# mobile
#crosswalk
mobile-experience
#chriswessels:hammer

# production
standard-minifier-js
ddp-rate-limiter
seba:minifiers-autoprefixer
fourseven:scss

# files

#dev
anti:fake

#maps
dburles:google-maps
mizzao:user-status
ostrio:files

Add accounts-base package explicitly to .meteor/packages

What do you get on: console.log(Accounts.onLogin, Accounts.onLogout)
What if you move accounts-base package above ostrio:files in .meteor/packages?
Which Meteor version you're on?

I get this if I set break point at files.coffee:501:

console.log(Accounts.onLogin, Accounts.onLogout)
VM64911:1 onLogin(func) {                                                                                //
      return this._onLoginHook.register(func);                                      … undefined

I tried to add it explicitly, but it doesn't help
Meteor version is <IP_ADDRESS>

I guess it's introduced in<EMAIL_ADDRESS>or<EMAIL_ADDRESS>

@epaminond If upgrade will help you - I'll update versionsFrom

@dr-dimitru, it works starting with <IP_ADDRESS> version.


Upgrade pydantic dependency to v2

Is your feature request related to a problem? Please describe.
Current version of healthchecks.io is incompatible with pydantic 2. There is an auto-update from dependabot in https://github.com/andrewthetechie/py-healthchecks.io/pull/700 however, due to major version upgrade, we need to do a bit more work to make it compatible with pydanticv2.
I'm using py-healthchecks.io along with another library that depends on pydantic v2, and due to the version conflict, I'm currently unable to use py-healthchecks.io.
Describe the solution you'd like
It would be great for py-healthchecks.io to support pydantic v2
Describe alternatives you've considered
We could keep it as is, but I imagine more and more libraries will be upgrading their pydantic dependency. Therefore, in order to keep py-healthchecks.io usable for other users, I recommend upgrading the version.

@Mariatta ty for opening a ticket. I would be happy to review and approve a PR that updates this project to use Pydantic 2

Thanks @andrewthetechie. I've created a PR at #702

@Mariatta thank you for your contribution. I don't use All-Contributors on this repo right now because its docs are still in RST format, but when I make that upgrade I'll make sure you're added.
Your change will be included in https://github.com/andrewthetechie/py-healthchecks.io/pull/671. I'm going to merge a few version bumps first and then try to get 0.4.3 out later today

Thank you!

I'd love some details on how you're using the library if you're free to share them. Its always exciting when someone new shows up using something I put together.
This library was a quick weekend project and I haven't thought about it much in a while

@Mariatta 0.4.3 is available now https://pypi.org/project/healthchecks-io/0.4.3/

Thank you @andrewthetechie!


SecurityParser returns package private class

https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs2/src/main/java/io/swagger/v3/jaxrs2/SecurityParser.java
The public method getSecurityScheme returns an optional with a package private class. Either the method should be package private, or the class it returns should be public.
Thanks!

thanks for reporting this! fixed in #2932


weird fixes url added in commit message

Happened while landing https://github.com/nodejs/node/pull/37559
deps: upgrade npm to 7.6.0

PR-URL: https://github.com/nodejs/node/pull/37559
Fixes: https://github.com/hidden
Reviewed-By: Luigi Pinca<EMAIL_ADDRESS>Reviewed-By: Rich Trott<EMAIL_ADDRESS>Reviewed-By: Michaël Zasso<EMAIL_ADDRESS>

FWIW it has picked it up from the issue description:

fix: hidden lockfiles were not respected on Node v10.0-10.12

That's a duplicate of https://github.com/nodejs/node-core-utils/issues/233


HDFS-16070. DataTransfer block storm when datanode's io is busy.

3105

 Quality gate: Failed
2 Issues

 1 Vulnerabilities
 1 Code issues

Details


Replace run_in_state with resource for more flexibility

What problem does this solve?
Currently we have run_in_state function to run the plugin only in specific state. But the approach is quite limiting because in games you often need to dynamically disable the input (for example, when you open menu or chat) and Bevy is moving to the stageless approach which will require users to split UI and game states.
What solution would you like?
I would suggest to introduce a resource which allows to disable input if present.
How could this be implemented?
We could query the optional component here:
https://github.com/Leafwing-Studios/leafwing_input_manager/blob/1e95c4c4a8d7041a51b83ec6bd89a3146694e5f1/src/systems.rs#L40
And do not update ActionState if it present. Also we should add a separate system which clears ActionState on DisableInput insertion.

Closed by #106.


Add message to fix API

Resolves #1454.

I'm now wondering if the fix message should instead be part of the CheckKind API, and not a custom thing like this.


OCPBUGS-17322: linuxptp-daemon pod status changes to Error and CrashLoopBackOff after a ptpconfig is loaded

Fixed nil pointer check

/jira refresh

/jira refresh


Paste from clipboard does not work for molecules in macro mode

Steps to Reproduce

Go to Molecules mode
Draw Benzene
Go to Macromolecules mode
Select Benzene
Press Ctrl+C
Press Ctrl+V

Actual behavior
Structure is not pasted to canvas
Expected behavior
Structure is pasted to canvas
Ketcher version [e.g. v2.4.2].
v2.22.0-rc.4

https://github.com/epam/ketcher/assets/62464241/1ebd022a-eb18-4317-84fe-b49baef6c5e7
Tested.
Desktop:

OS: Windows 11
Browser Chrome
Version 124.0.6367.79 (Official Build) (64-bit)

Ketcher version
[Version 2.22.0-rc.5]
Indigo version
[Version 1.21.0-rc.1]


Update regular expression for header flag

Follow up for https://github.com/kevmoo/dhttpd/pull/61 to allow more characters in the header value

What about adding support for Content Security Policy headers as well? This type of header deviates a bit from the standard header=value syntax.
If we want to keep the flag approach, the regex could be changed as follows:
final _header_key = r'[\w-]+';
final _header_value = r'[\w-]+';
final _csp_header_value = r"(?:[\w-]+(?: [A-Za-z0-9-._~:/?#\[\]@!$&'()*+,%=]+)+(?:; )?)+";
final _delimiter = r';|$';
final _regex= RegExp('(${_header_key})=(${_header_value}|${_csp_header_value})(${_delimiter})');

However, this expression still fails to capture some types of headers (like the Reporting-Endpoints header), which are not straightforward to implement. Therefore, perhaps it would be a good idea to revisit the option of passing headers with a (JSON) file. What do you think @johnpryan?
Here you can find some regex examples with the proposed expression: https://regex101.com/r/8dE5UW/3

@Alejandro-FA I think a JSON file makes more sense overall - maybe that's a better long-term solution than making patches to the regex.


Conditional formatting for Nullable values

I do not understand from the Conditional Formatting Syntax chapter  how to test for null values of numeric properties.
This is an example that doesn't produce expected result:
using System;
using SmartFormat;

public class Point
{
	public double? Lat { get; set; }
	public double? Lon { get; set; }
}

public class Program
{
	public static void Main()
	{
		var point = new Point {Lat = 23.45};
		Console.WriteLine(Smart.Format("Latitude: {Lat:{}|N/A}, longitude: {Lon:{}|N/A}", point));

		// Output is:
		// Latitude: N/A, longitude: N/A

		// Output I want is:
		// Latitude: 23.45, longitude: N/A
	}
}

You can run it in this fiddle.

Well, there currently is no special support for Nullable<T> in the ConditionalFormatter, which means it should default to the "value|null" behavior, as you expected.
And, indeed, the logic at L155 of ConditionalFormatter.cs
compares the value to null.
So, I'd qualify this as a bug.

Perhaps this is caused by "boxing" the Nullable in an object?  I thought that Nullables still work, even when boxed.

Related: #39

As a quick workaround I've changed L91-98 of ConditionalForamtter.cs to
paramIndex = 0;

@thexray That's unexpected ... if that worked, then it means "currentIsNumber" must be true, which means current is double returns True?  Do Nullables work this way?

Ok, I figured some stuff out...
As seen in this fiddle, (decimal?)null is decimal is False, but (decimal?)5 is decimal is True!  This is quite surprising, but I guess it makes sense.  I'm guessing that the Nullable type has an implicit type coverter to Object that causes this behavior.

So, this still provides an interesting challenge.  When the Nullable is casted to an Object, it actually "unwraps" itself into either null, or the native number type.  This means that "null" values will use the "object" logic, but non-null values will use the Number logic.
I think we need to explicitly check for the "Nullable" data type, and force it to use the "object" logic.
Is there an easy way to check if a type is nullable?

Yes it is!
if (type.IsGenericType && type.GetGenericTypeDefinition() == typeof(Nullable<>)) {…}
Source: http://msdn.microsoft.com/en-us/library/ms366789.aspx

Ok, thanks for the link.  According to that link, it's NOT possible:
"
Calling GetType on a Nullable type causes a boxing operation to be performed when the type is implicitly converted to Object. Therefore GetType always returns a Type object that represents the underlying type, not the Nullable type.
"
To put it in my own words: when any Nullable is cast to object, it loses its "nullability".  It either gets cast to null, or cast to the underlying data type.
So within the Conditional Formatter code, it's actually impossible to tell if current was nullable, because it was converted to object and lost its original type.
This actually might be extremely difficult to solve.

Well, it's not possible in our case :)
I didn't had a look at our code...
Can we save the original value anyhow? Or store the nullability info
separately as meta data?

Well, I think the only possibility is for the Reflection plugin to detect if it's Nullable.
Then it'd have to store that as a flag somewhere.  I don't think any of this is trivial.

I've got a solution in the works.
I've been working on a "named formatters" feature that allows you to choose which formatter you want to use, in addition to passing in options.
This feature will allow you to specifically check for "null" values, and won't use "index" logic if it's a number.
This feature is slated for v1.3.

Alright, this feature has been implemented, and v1.4 is released.
Basically, there's a new "choose" binding that lets you specifically target null values.
This ought to work:
Smart.Format("Latitude: {Lat:choose(null):N/A|{}}, longitude: {Lon:choose(null):N/A|{}}", point);


added the ability to disable space sanitization

Space sanitization can sometimes be too sensitive for an initial pass, so i added the ability to disable it.

Codecov Report

Merging #22 (1f7e2c3) into master (39ccb87) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #22   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           79        84    +5
=========================================
+ Hits            79        84    +5

Impacted Files
Coverage Δ

goaway.go
100.00% <100.00%> (ø)

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 39ccb87...1f7e2c3. Read the comment docs.

Looks good to me!
Thank you for your contribution!

Released in v1.4.0


Installed @serverless-guru/prettier-plugin-import-order; setup import order rules

Current dependencies on/for this PR:

main

PR #1476   👈

This comment was auto-generated by Graphite.


10412 - update Fas UI text

Issue #: /bcgov/entity/10412
Description of changes:

Update FAS UI text and remove lorem ipsum fillers

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

increase version number in package also


[libwebp] Fix debug postfix and build

Add a debug postfix to libwebp, to simplify
finding the debug library in CMake, consistently
with most other libraries in vcpkg.
Add the mux directory that was not built
in the CMake-based build system.

Hi @traversaro, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

Much appreciated, thanks!

Since the output is modified, I will bump the version in the CONTROL file.


Cannot find module ./src/exports.js

when i try running an example i get this error

when i move it to discord-user-bots package folder i have error cannot find module node:fs

The examples given are made to run in the folder they are in. If you wanted to run the examples yourself without git cloning the project, then replace "./src/exports.js" with "discord-user-bots".


Fixin the bugs like that

I haven't been around for a while, and come back to discover 122 open issues have accumulated. C'mon, guys, try to fix bugs once and a while rather than just adding, adding, and adding some more, OK?

The new code generates some RuboCop offenses.

Yep, I'll fix it up soon. No time right now, sorry.

Take your time.

:+1: All changes look good to me.

Thanks for review, @jonas054. I'll see if I can fix up those last remaining style problems tonight.

Should be good now. Let's just make sure the CI build passes.

👍

Thanks @bbatsov. Now there are only 107 open issues... gulp...

Next week I might get to squashing a few of those myself. Too much work, too little time for anything else...


[NDM] Add mock Cisco SDWAN API server

What does this PR do?
Adds a mock API server
Useful for integration testing of the Cisco SD-WAN API

Motivation
NDMII-2575

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Current dependencies :

[NDM] Add mock Cisco SDWAN API server

[NDM] Add Cisco SD-WAN payload processor

[NDM] Add Cisco SD-WAN metrics and metadata sender

[NDM] Add Cisco SD-WAN corecheck

/merge


After 1003 concurrent connections client 98959 EXIT: {shutdown,emfile} exceptions is coming

I am trying to connect to 100000 connections to emqttd. But after 1003 connections i am getting client 98959 EXIT: {shutdown,emfile} exception but as per configuration it has to handle 1M connections(I have done as per documentation). In jmeter, it is reaching 100000 connections. But if I am  trying using emqttd benchmark code it is reaching up to 1003 only.
./emqtt_bench_pub -h <IP_ADDRESS> -p 1883 -c 100000 -i 100 -I 2000 -t bench/%i -s 256

Hi, @VIKRAMAS Could you tune the file limit os params?  https://developer.emqx.io/docs/emq/v3/en/tune.html

I have the same problem. but when i check the open files num:
ulimit -a
open files ..........  1024

it's only 1024，so your 1003 may be limited by this number
and i set it higher：
ulimit -n 1000000

then it works fine.


Bug when adding vector to a matrix

I'm encountering a bug when adding a vector to a matrix as described in the docs. The following works:
val dm = DenseMatrix((1.0,2.0), (3.0,4.0))
dm(::, *) + DenseVector(1.0, 1.0)
res2: breeze.linalg.DenseMatrix[Double] =
2.0  3.0
4.0  5.0

But if I add a 3rd row to the matrix, and try to add the same vector to it, I get an error:
val dm = DenseMatrix((1.0,2.0), (3.0,4.0), (5.0, 6.0))
dm(::, *) + DenseVector(1.0, 1.0)
java.lang.IllegalArgumentException: requirement failed: Vectors must have same length: x.length == y.length (2 != 3)
  at breeze.linalg.DenseVector$canDaxpy$.apply(DenseVector.scala:694)
  at breeze.linalg.DenseVector$$anon$13.apply(DenseVector.scala:684)
  at breeze.linalg.DenseVector$$anon$13.apply(DenseVector.scala:682)
  at breeze.linalg.operators.DenseVector_GenericOps$$anon$312.apply(DenseVectorOps.scala:774)
  at breeze.linalg.operators.DenseVector_GenericOps$$anon$312.apply(DenseVectorOps.scala:771)
  at breeze.linalg.BroadcastedColumns$$anon$4.$anonfun$apply$3(BroadcastedColumns.scala:95)
  at breeze.linalg.BroadcastedColumns$$anon$4$$Lambda$5532.000000005CDEAB90.apply(Unknown Source)
  at breeze.linalg.DenseMatrix$$anon$19.$anonfun$apply$2(DenseMatrix.scala:881)
  at breeze.linalg.DenseMatrix$$anon$19.$anonfun$apply$2$adapted(DenseMatrix.scala:880)
  at breeze.linalg.DenseMatrix$$anon$19$$Lambda$5533.000000005CDEB9B0.apply(Unknown Source)
  at scala.collection.immutable.Range.foreach(Range.scala:190)
  at breeze.linalg.DenseMatrix$$anon$19.apply(DenseMatrix.scala:880)
  at breeze.linalg.DenseMatrix$$anon$19.apply(DenseMatrix.scala:877)
  at breeze.linalg.BroadcastedColumns$$anon$4.apply(BroadcastedColumns.scala:95)
  at breeze.linalg.BroadcastedColumns$$anon$4.apply(BroadcastedColumns.scala:93)
  at breeze.linalg.NumericOps.$plus(NumericOps.scala:153)
  at breeze.linalg.NumericOps.$plus$(NumericOps.scala:152)
  at breeze.linalg.BroadcastedColumns.$plus(BroadcastedColumns.scala:30)
  ... 38 elided

It looks like this issue happens if the number of rows in the matrix go higher than the length of the vector, i.e with 2 rows and a 2D vector, it works, but with 3 rows, it fails.
Any ideas why this is? Its got to be a bug, right? I'd be happy to try to send a pull to fix this, if given some pointers.

Stackoverflow indicates this wasn't an issue in the past: https://stackoverflow.com/questions/46025694/add-a-vector-to-every-column-of-a-matrix-using-scala-breeze
Looks like this assert should just be removed: https://github.com/scalanlp/breeze/blob/8c216beb11cce13ea97559835ee1c65fcd3df2bc/math/src/main/scala/breeze/linalg/DenseVector.scala#L708

Hey,
I do not know if this is still up to date, but I think the assert is at the right place.
dm in your second example has 3 rows and 2 columns:
DenseMatrix((1.0,2.0), (3.0,4.0), (5.0, 6.0))
2.0  3.0
4.0  5.0
6.0  7.0

So adding a 2 rows vector should result in a fail.
However, you can add a 3 row vector : dm(::, *) + DenseVector(1.0, 1.0, 1.0), or broadcast through rows: dm(*, ::) + DenseVector(1.0, 1.0)


CI: separate stages for tests and deplay

Based on #164 and will be rebased once that one is merged.
Only last 2 commits to be reviewed (c1ac7bb, aac225c).
This is refactoring of .travis.yml structure, so it now has:

simple and explicit structure using build stages
test and deployment Jobs are run at separate stages (in parallel inside single stage)
each job has a clear name in UI in English
deployment stage is conditionally triggered only on tag

Effect on CI time (measured by last build time):

before 8 min 4 sec

after 6 min 29 sec

rebased on latest master


Something wrong with github actions workflow where the access token is bad.

Re-running it locally using all the same data worked 100% fine.

Also, re-running it locally and just committing the new strava_tokens.json.gpg also works totally fine


txnkv: RangedKVRetriever struct to provide custom range data operations

Refer: https://github.com/pingcap/tidb/issues/26952
To make a better implement for temporary table. It is required that snapshot can read data from other sources like memory for some specified ranges. So we expect KVSnapshot can provide some methods to override data fetch.
The draft has been proposed here: #262 . This pr is the first step, introduce a struct to provide custom range data operations.
Signed-off-by: Chao Wang<EMAIL_ADDRESS>

It seems the new method
Scan(startKey []byte, endKey []byte, reverse bool) (Iterator, error)

is almost the same like the combination of the two old methods (except for ReverseIter does not have bound)
Iter(k []byte, upperBound []byte) (Iterator, error)
IterReverse(k []byte) (Iterator, error)

Is it possible to merge them together?

It seems the new method
Scan(startKey []byte, endKey []byte, reverse bool) (Iterator, error)

is almost the same like the combination of the two old methods (except for IterReverse does not have bound)
Iter(k []byte, upperBound []byte) (Iterator, error)
IterReverse(k []byte) (Iterator, error)

Is it possible to merge them together?

They are a little different for iter reverse. For Scan it can support both start and end are not nil, it is a required feature. But current IterReverse do not support it.

It seems the new method
Scan(startKey []byte, endKey []byte, reverse bool) (Iterator, error)

is almost the same like the combination of the two old methods (except for IterReverse does not have bound)
Iter(k []byte, upperBound []byte) (Iterator, error)
IterReverse(k []byte) (Iterator, error)

Is it possible to merge them together?

They are a bit different for iter reverse. For Scan it can support both start and end are not nil, it is a required feature. But current IterReverse do not support it.

Can we add lowerBound to IterReverse?

It seems the new method
Scan(startKey []byte, endKey []byte, reverse bool) (Iterator, error)

is almost the same like the combination of the two old methods (except for IterReverse does not have bound)
Iter(k []byte, upperBound []byte) (Iterator, error)
IterReverse(k []byte) (Iterator, error)

Is it possible to merge them together?

They are a bit different for iter reverse. For Scan it can support both start and end are not nil, it is a required feature. But current IterReverse do not support it.

Can we add lowerBound to IterReverse?

I think it's a good idea. I searched the current code, only uSnapshot delecars a method IterReverse but its a internal interface. Adding lowerBound to IterReverse for Retriever is fine.
Iter(k []byte, upperBound []byte) (Iterator, error)
IterReverse(k []byte, lowerBound []byte) (Iterator, error)

If one day

Done

@disksing  PTAL again

It should moved to tidb if it is currently only used by temporary table


Check MCG.Reconcile strategy before deleting Noobaa resources

Delete Noobaa resources only they are being managed
by the OCS operator.
Signed-off-by: N Balachandran<EMAIL_ADDRESS>

/assign jarrpa

Should the same checks be done for the other Managed resources as well?

I think this makes sense thus far.

Should the same checks be done for the other Managed resources as well?

Now that you mention it, that doesn't sound like a bad idea. @raghavendra-talur or @iamniting do either of you have any thoughts on that?

Delete Noobaa resources only they are being managed
by the OCS operator.

@nbalacha I think 'if' is missing here.
Can you pls prefix "StorageCluster:" as we are following that pattern for all our delete or uninstall commits.
[1]. https://github.com/openshift/ocs-operator/blame/fac013610cf1bf1f0f50ae9c7f17d2163e004055/pkg/controller/storagecluster/uninstall_reconciler.go


Missing files in npm build?

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '[...]\node_modules\sveltekit-adapter-html-like\adapter.js' imported from '[...]\node_modules\sveltekit-adapter-html-like\index.js
After checking the files, the adapter.js and platforms.js files are missing. But they are being imported from the index.js file

Closing because might be related to me installing it using yarn instead of npm

No, you were right: there were files missing from distribution. Released a small fix, next up is migrating to SvelteKit 1.0!


Event classes and tagging variables (as hadronness)

Proposal: keep the format general enough so we can compute the flux of a source (or even a diffuse flux) either from the number of events surviving a cut in or from a fit to a “hadronness” distribution. I argue that this later method should be more performant at high contamination (low separation power) because in principle all events are kept and the whole information of the differences in hadronness pdfs is used. I also think this may be a road to work in cases where our separation power is small, like electron analysis.
Use case: we want to be able to compute the flux of a source using both methods
Case 1: Using cuts:

Define a set of event classes corresponding to different cuts in hadronness
Compute  the effective area for each set of cuts Aeff(cut)
Compute the background for each set of cuts from data N_bckg(cut)
Count the number of events passing the cuts N_evts(cut)
Compute the signal events N_sig(cut) = N_evts(cut)-N_bckg(cut)
Flux(cut) = (N_sig(cut))/(Aeff(cut)*time)
Required: Class definitions, class for each event, Aeff(Cut), Backg(cut)

Case 2: Fitting the distributions:

Keep the hadronness of each event
Compute the pdf  for the signal hadronness_pdf(sig)
Compute the pdf  for the background hadronness_pdf(bckg)
Fit the hadronness distribution of the sample to
N_sig_hadronness_pdf(sig)+N_bckg_hadroness_pdf(bckg)
Flux  = N_sig/(Aeff*time)
Required: hadroness for each evt, hadroness_pdf(evts), hadronness_pdf(bckg)

Note: A soft hadronness cut will be needed in any case to reduce the DL3 size

@contrera - Thank you for the proposal!
I think it would be nice to support more event info and those use cases in IACT DL3.
For me the way forward would be a pull request proposing changes and then discussing which extra info should be required or optional.
@jknodlseder @TarekHC, maybe @woodmd with the Fermi-LAT perspective - Thoughts?

Hi all,
I think there should be a natural way of adding this king of "lower level" variables. Also, EVT3 should contain events surviving a set of cuts, which could be also flexible on demand (providing a list of possible cuts to the proposals, defined by the use cases we may think of). Adding new sets of cuts to this list should also be natural, when different use cases appear (for example, no hadroness cut). Then, they should also be included into the IRFs as new event classes (additional axes?).
Maybe we could add to the specs some words on the flexibility of the format. How additional columns could be easily added (both within the event list and as IRF axes) giving as an example Fermi's event class.

Just a note: @MaxNoe made some comments related to this issue in #119  #120 and especially #121 .
I closed all of those, so discussion should continue here.

Hello, could we restart this discussion?
What would be the argument against having an additional column representing the outcome of the event classification (a gammaness or hadronness).
I think any gamma-ray astronomical instrument discriminate gamma-rays from hadrons with some classification algorithm.
Thoughts?

Hello, could we restart this discussion?
What would be the argument against having an additional column representing the outcome of the event classification (a gammaness or hadronness).
I think any gamma-ray astronomical instrument discriminate gamma-rays from hadrons with some classification algorithm.
Thoughts?

Aside comment maybe. I prefer gammaness because the background can be made not only of hadrons (electrons, heavier nuclei)

Aside comment maybe. I prefer gammaness because the background can be made not only of hadrons (electrons, heavier nuclei)

Remember we have only 8 characters for FITS keywords though, so it should be GAMMANES or something like that :grin:

Remember we have only 8 characters for FITS keywords though, so it should be GAMMANES or something like that :grin:

I think you are looking for a column name, not a keyword. FITS column names can be more than 8 characters.

Le 29 janv. 2021 à 10:56, Cosimo Nigro<EMAIL_ADDRESS>a écrit :
Remember we have only 8 characters for FITS keywords though, so it should be GAMMANES or something like that 😁
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/34#issuecomment-769703898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW2QV37DL3XDIUVIKUAA6DS4KA6XANCNFSM4CALPD2Q.

I think you are looking for a column name, not a keyword. FITS column names can be more than 8 characters.

Le 29 janv. 2021 à 10:56, Cosimo Nigro<EMAIL_ADDRESS>a écrit :
Remember we have only 8 characters for FITS keywords though, so it should be GAMMANES or something like that 😁
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/34#issuecomment-769703898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW2QV37DL3XDIUVIKUAA6DS4KA6XANCNFSM4CALPD2Q.

Hi all,
I think it would indeed make sense to add an optional gammaness column to the event lists, and I fully support it. Although we encounter again with the classical problem: if we add that column, we would need IRFs also evolving in bins of gammaness (including of course the background model).
This is a problem that will come again and again: there are variables that, in order to be useful, they need to be added both to the event lists and to the IRFs as an additional dimension (event types, gammaness, zenith, azimuth, etc...), and science tools right now (as far as I know, but @jknodlseder and @adonath may confirm) are not ready to support (their shape is hard coded, as far as I know).
Could we find a general way to define (and specially) implement such variables? I personally feel this repo needs to describe them, to at least guide a future implementation by science tools.

Hi all,
I think it would indeed make sense to add an optional gammaness column to the event lists, and I fully support it. Although we encounter again with the classical problem: if we add that column, we would need IRFs also evolving in bins of gammaness (including of course the background model).
This is a problem that will come again and again: there are variables that, in order to be useful, they need to be added both to the event lists and to the IRFs as an additional dimension (event types, gammaness, zenith, azimuth, etc...), and science tools right now (as far as I know, but @jknodlseder and @adonath may confirm) are not ready to support (their shape is hard coded, as far as I know).
Could we find a general way to define (and specially) implement such variables? I personally feel this repo needs to describe them, to at least guide a future implementation by science tools.

I think you are looking for a column name, not a keyword. FITS column names can be more than 8 characters.

Thanks @jknodlseder, I didn't know.

there are variables that, in order to be useful, they need to be added both to the event lists and to the IRFs as an additional dimension

I think it will take a while to have the IRF defined also as a function of the gammannes. Note I am proposing to include this as an optional column (like optional are all those Hillas, IACT-related features we just ignore).
If some corresponding information has to be included in the IRF can we just add a header keyword?
If I generate an IRF with a theta2 cut I will store all the EVENTS RA and DEC anyhow and add RAD_MAX in the header.
Can we do the same for the gammanness. We store all the events gammanes and then we add a GAMMACUT (or something like that) header keyword. What do you think?

I think you are looking for a column name, not a keyword. FITS column names can be more than 8 characters.

Thanks @jknodlseder, I didn't know.

there are variables that, in order to be useful, they need to be added both to the event lists and to the IRFs as an additional dimension

I think it will take a while to have the IRF defined also as a function of the gammannes. Note I am proposing to include this as an optional column (like optional are all those Hillas, IACT-related features we just ignore).
If some corresponding information has to be included in the IRF can we just add a header keyword?
If I generate an IRF with a theta2 cut I will store all the EVENTS RA and DEC anyhow and add RAD_MAX in the header.
Can we do the same for the gammanness. We store all the events gammanes and then we add a GAMMACUT (or something like that) header keyword. What do you think?

@cosimoNigro We would also need a table for energy dependent cuts.

@cosimoNigro We would also need a table for energy dependent cuts.

We can start with a fixed hadronness cut (as we do now for theta2 or RAD_MAX), no?
At the moment we do not support energy-dependent theta2 cuts.

We can start with a fixed hadronness cut (as we do now for theta2 or RAD_MAX), no?
At the moment we do not support energy-dependent theta2 cuts.

@cosimoNigro We already have a RAD_MAX table for energy / fov dependent cuts. I don't see a reason why we should restrict us to a global gammaness cut, we know its not sufficient.

@cosimoNigro We already have a RAD_MAX table for energy / fov dependent cuts. I don't see a reason why we should restrict us to a global gammaness cut, we know its not sufficient.

Sorry, but I don't understand:

Why would you store the gammaness of each event, if all you want is to store a gammaness cut? The only reasonable reason to store the gammaness as an events table column at DL3 level would be to actually allow science tools to use that parameter. And if no IRFs vs gammaness are stored, then we don't need that parameter in the events table. Of course maybe I'm mistaken, can you please tell me a use case in which science tools would need that gammaness per event (not requiring IRFs vs gammaness)? The only one I can think of would be e.g. pulsars analysis, but if a detection is made (no need for IRFs for just a detection) you would want to calculate a spectrum, and then you would of course need IRFs.

If it is just a matter of provenance (knowing the gammaness cut vs energy that was used for that DL3 run) then I agree we would need to store it somewhere (but probably no need to add it to the events table). Although there is a key difference with, for instance, the theta2 cuts: science tools do need to know the theta2 cut that was used to generate the IRFs (in order to use the same cuts, as theta2 is indeed used in the analysis as it is a known parameter per event). Unless I'm mistaken, you may use complex gammaness cuts vs energy, and as long you are consistent between all your runs, MCs calculating IRFs and OFF data, then science tools would not need to know those cuts at all.

So, long story short: first decide if we want to add the parameter for a specific high-level analysis or just for provenance. Once we know what we want, then we may find a suitable solution.

Sorry, but I don't understand:

Why would you store the gammaness of each event, if all you want is to store a gammaness cut? The only reasonable reason to store the gammaness as an events table column at DL3 level would be to actually allow science tools to use that parameter. And if no IRFs vs gammaness are stored, then we don't need that parameter in the events table. Of course maybe I'm mistaken, can you please tell me a use case in which science tools would need that gammaness per event (not requiring IRFs vs gammaness)? The only one I can think of would be e.g. pulsars analysis, but if a detection is made (no need for IRFs for just a detection) you would want to calculate a spectrum, and then you would of course need IRFs.

If it is just a matter of provenance (knowing the gammaness cut vs energy that was used for that DL3 run) then I agree we would need to store it somewhere (but probably no need to add it to the events table). Although there is a key difference with, for instance, the theta2 cuts: science tools do need to know the theta2 cut that was used to generate the IRFs (in order to use the same cuts, as theta2 is indeed used in the analysis as it is a known parameter per event). Unless I'm mistaken, you may use complex gammaness cuts vs energy, and as long you are consistent between all your runs, MCs calculating IRFs and OFF data, then science tools would not need to know those cuts at all.

So, long story short: first decide if we want to add the parameter for a specific high-level analysis or just for provenance. Once we know what we want, then we may find a suitable solution.

I agree with @TarekHC here. I think the "gammaness" will never be a parameter that users can freely cut on for a high level analysis. I think it's rather going into a direction of predefined event classes (as Fermi-LAT does...) optimised for different analysis scenarios. Except if users possibly produce the IRFs themselves as well at some point... As @TarekHC noted the challenge is to deliver the corresponding IRFs  for each selection as well.
From a science tools perspective I think event classes are typically not analysed jointly, so it's a choice made at the beginning of the analysis, such as the energy range and that's it. In that sense the concept of "event types" (using Fermi-LAT terminology) is more relevant as it requires to jointly fit multiple types of events (such as PSF classes etc.) together and I think both science tools are ready for this.
In general I agree, that the event list can contain (optional) additional information, that is not necessarily used for an analysis, but is useful for e.g. debugging and diagnostic plots. The only argument against it would be that the information could be mi-used by users...

I agree with @TarekHC here. I think the "gammaness" will never be a parameter that users can freely cut on for a high level analysis. I think it's rather going into a direction of predefined event classes (as Fermi-LAT does...) optimised for different analysis scenarios. Except if users possibly produce the IRFs themselves as well at some point... As @TarekHC noted the challenge is to deliver the corresponding IRFs  for each selection as well.
From a science tools perspective I think event classes are typically not analysed jointly, so it's a choice made at the beginning of the analysis, such as the energy range and that's it. In that sense the concept of "event types" (using Fermi-LAT terminology) is more relevant as it requires to jointly fit multiple types of events (such as PSF classes etc.) together and I think both science tools are ready for this.
In general I agree, that the event list can contain (optional) additional information, that is not necessarily used for an analysis, but is useful for e.g. debugging and diagnostic plots. The only argument against it would be that the information could be mi-used by users...

Yes, indeed. You do not to know gammaness cuts for the analysis of already selected events for DL3 data. However, for provenance it might be good to define it in the standard.

Yes, indeed. You do not to know gammaness cuts for the analysis of already selected events for DL3 data. However, for provenance it might be good to define it in the standard.

Hi @TarekHC, @adonath,
sorry for the late reply.

can you please tell me a use case in which science tools would need that gammaness per event (not requiring IRFs vs gammaness)?

I have at least 2:

In this paper they included the information of the PSF (i.e. theta2 distribution) in the significance estimation. @micheledoro is working on a similar method but using also the gammaness distribution of the events also. You basically require that the events follow both the theta2 and hadronness distribution of MC events;
In this other paper events that are normally discarded by a cosmic-ray rejection criterion (i.e. events above a standard gammaness cut you might have applied) are used to build a "template background". Instead of estimating the background from another region of the camera you would use photons in the same region of the source but with a different gammaness value.

Both are science cases related more to the estimation of the excesses and their significance (no IRF involved), but I think valid to consider. Especially if they can be enabled by adding an optional column.
Let me know what you think.

Thanks @cosimoNigro for the references!
The main point in my previous comment was, that I think the selection  on "gammaness" will not be part of the "standard analysis" that is typically done by users. By "standard analysis" I mean flux measurements, based on likelihood fitting (1D, 2D, 3D, etc.). Letting users freely cut on the "gammaness" in these analysis scenarios, introduces the challenge of delivering the corresponding IRFs for a given cut. "Logistically" I think this can only be solved with pre-defined cuts (aka "event classes") or giving the user the possibility to produce their own IRFs (which might be a good option for some special analysis use-cases!).
The references you linked I would classify as "non-standard" use cases, I think the first method is basically a way to derive a PSF model from data, which might be interesting for cross-checks of simulated IRFs, or for analyses where no IRFs are available yet. But I'm not sure it's something a "normal", user would do. However once the user selects on the "gammaness" parameter, the analysis is basically limited to significance estimation and source detection, which I think limits the amount of (astrophysically...) useful analyses a lot.
In general I don't have any objections at all to include a "gammaness" column  in the event list format as long as it's optional. But I also think it will probably never be "natively" supported by the science tools, which is also fine I guess. I completely agree, that advanced users should have the freedom to read an event list "by hand" and do any kind of special analysis they want.

Thank you @cosimoNigro for those use cases, they are indeed valid cases to be considered for discussion. I remember some of these were discussed in the past when defining DL3 specs (and I add some comments below). Other use cases discussed were cosmic ray abundance studies or electron spectrum measurements, which will obviously also need other kind of datasets, simulations, etc... And that does not mean we need to accommodate DL3 to also allow such science cases (as there was consensus that those analyses would be done internally by the collaboration, and perhaps in the future released with their own data format).
But I essentially agree with @adonath. If we want to add ´gammaness´ as an optional column I'm ok with that. But it should be noted that it would go slightly against the current DL3 "philosophy", and I doubt science tools would actually use it any time soon. In the end, it is a matter of definition: DL3 has always been defined as to contain "gamma-like events", as an equilibrium of simplicity and available use cases.
I see it equivalent to Fermi-LAT data format: with time it evolved to include more event parameters (e.g. additional event types), which significantly improved sensitivity and resolution. But they never allowed external LAT members to play around with those until they were confident to include them in their standard data products.

In this paper they included the information of the PSF (i.e. theta2 distribution) in the significance estimation. @micheledoro is working on a similar method but using also the gammaness distribution of the events also. You basically require that the source events follow both the theta2 and gammaness distribution of MC events;

Yes, indeed, you could use it as an attempt to improve your sensitivity. But only allowing analyzers to detect a source with one method, and not allow them to go any farther than that (no flux estimation?) would probably not be very useful.
If such an approach was indeed explored by CTAO/CTAC, and proven to work, then we would need to add gammaness to both the event lists (to apply the method to detect the source with improved sensitivity) and to the IRFs (to estimate a flux with that same method). But for the moment, as @adonath was saying, such an analysis will probably be non-standard.

In this other paper events that are normally discarded by a cosmic-ray rejection criterion (i.e. events above a standard gammaness cut you might have applied) are used to build a "template background". Instead of estimating the background from another region of the camera you would use photons in the same region of the source but with a different gammaness value.

Yes, I remember this one, and it is a very good example of what you could (because you don't need IRFs vs gammaness). I'm guessing CTAO or CTAC would apply this method internally (with all the data available) to generate background models, and store these as DL3 (background models can indeed be considered IRFs themselves). It could perhaps make sense to allow external CTA people to actually be the ones in charge of implementing such methods... But that could in the end be a double edge sword...

If we add that column, we would need IRFs also evolving in bins of gammaness (including of course the background model).

I think this is not true. Just adding this column in a well-defined format as optional column would already help many people and tools to start building things around it. We don't have to immediately also specify it as a possible IRF axis.
So let's just add this column to the list of optional columns for EVENTS with a sane definition.
E.g. like this:
* ``GAMMANESS`` type: float
    * Classification score of a signal / background separation. SHOULD be between 0 and 1. Higher values MUST indicate
    larger confidence that this shower was induced by a gamma-ray.


Update LDAP.hx

haxe 4.0.1 compatible. With new php syntax

Hi byFd,
Please consider updating the lib.
Cheers

hey,
sorry for the late response, somehow i didn't get an email about this. i am not using haxe currently, but that stuff looks good. thanks for contributing :)

No worries, thank you for initiating this in the first place!
Le ven. 22 nov. 2019 à 11:26, Chris<EMAIL_ADDRESS>a écrit :

hey,
sorry for the late response, somehow i didn't get an email about this. i
am not using haxe currently, but that stuff looks good. thanks for
contributing :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/byFd/LDAP/pull/1?email_source=notifications&email_token=AACG3ZUDR4JUGCG2GZC7XYDQU6XTZA5CNFSM4JMINKK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE5HDEI#issuecomment-557478289,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACG3ZXL5LNRKN7VQP5LBETQU6XTZANCNFSM4JMINKKQ
.


fix remove logic of estimating count of rows to read in segment iterator to avoid wrong result of unique key (#29109)

Proposed changes
Pick from #29109

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run p1


Incorrect escaping of index names in _cat/indices API

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[x] elastic.v7 (for Elasticsearch 7.x)
[x] elastic.v6 (for Elasticsearch 6.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v2 (for Elasticsearch 1.x)
Please describe the expected behavior
I expect the program to return a list of all matching indices.
Please describe the actual behavior
It fails with elastic: Error 403 (Forbidden) errors.
Any steps to reproduce the behavior?

Create a ES Cluster which contains indexes like, index-2019.10.1, index-2019.10.2 and so on although just 2 are sufficient to demonstrate issue.

Build and run this bit of code on this cluster. All it does is connect to the cluster and get all indices that match index-2019.10

package main

import (
	"context"
	"fmt"
	stdlog "log"
	"os"

	"github.com/olivere/elastic/v7"
	log "github.com/sirupsen/logrus"
)

func main() {
	esAddr := "http://localhost:9200"

	esclient, err := elastic.NewClient(
		elastic.SetErrorLog(stdlog.New(os.Stderr, "ELASTIC ", stdlog.LstdFlags)),
		elastic.SetInfoLog(stdlog.New(os.Stdout, "", stdlog.LstdFlags)),
		elastic.SetURL(esAddr),
		elastic.SetSniff(false),
		elastic.SetHealthcheck(false),
	)

	v, err := getAllMatchingIndices(esclient,
		"index-2019.10.*")
	if err != nil {
		log.Error(err)
	}
	fmt.Println(v)
}

func getAllMatchingIndices(client *elastic.Client, srcIndexPattern string) ([]string, error) {
	out, err := client.
		CatIndices().
		Columns("index").
		Index(srcIndexPattern).
		Do(context.Background())
	if err != nil {
		return nil, err
	}
	list := make([]string, len(out))
	for i, v := range out {
		list[i] = v.Index
	}
	return list, nil
}

That's it. This program will fail with access denied errors.

Whereas, If you send a similar request manually with curl, It'll work just fine.
curl http://localhost:9200/_cat/indices/index-2019.10\*\?format\=json\&h\=index

The issue here is incorrect escaping of index. The relevant code is in cat_indices.go.
I am not fully aware of what a index should look like after escaping but here is what path ends up looking like in this case,

_cat/indices/index-2019.10.%2A

i.e. * is replaced with %2A which messes with Elasticsearch's http API.
I tried couple of different inputs like passing, index-2019.10.\\* and replacing "index-2019.10.*" with "index-2019.10.*" (raw literals, wrapped with backticks) but neither of these worked. The library just escapes absolutely everything.

In v7 API, Requests delete index endpoint are also incorrectly escaped.
A request like, -X DELETE <host>/index_1,index_2,index_3 is escaped to -X DELETE <host>/index_1%2Cindex_2%2Cindex_3 which then results in 403 errors. Commas should not be escaped in this case.

I've added two integration tests in https://github.com/olivere/elastic/commit/5c0861c21dfa010ad37a270bd6cc16127deb824c to check the behaviour. I can't reproduce the reported issue.
Feel free to send a reproducible test case and I can reopen to inspect.


Support for specifying route name in form tag helper

Issue - #1489
@dougbu @NTaylorMullen

:shipit: once you've fixed the comment @NTaylorMullen mentioned

:shipit: once you've addressed the test comments.


mgmt trafficmanager, regen code

Description
link https://github.com/Azure/azure-sdk-for-java/issues/29991
manual code c45d55f66a11cf4b0159f365add0ff78f959e8df :
Service needs id, name and type in EndpointInner for updating TrafficManagerProfile.
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-trafficmanager

We might want to take a look on codegen later.
Codegen should be able to find that id/name/type is not read-only (as in ProxyResource in azure-core-management) in this case, and generate them in the EndpointInner class.
This logic might be broken due to that Endpoint extends ProxyResource in swagger and then that extends Resource in swagger again (where these properties in Resources in not read-only).
The standard definition should be read-only https://github.com/Azure/azure-rest-api-specs/blob/main/specification/common-types/resource-management/v2/types.json#L9

Logged the issue here: https://github.com/Azure/autorest.java/issues/1564


Application components and environment details

Hi
I am planning to host the dashboard in Ubuntu. Can you please provide the details on the application components.
Also please let me know if can we host all the components on the server. Also let me if you have sizing details for the hosting server (CPU, Memory and Storage)\
Thanks,
Deepak

Team, quick response will be much appreciated.

It will depend upon the amount of data you are expecting to store etc.
Give me some estimate on (1) how many git repositories (2) how many total jenkins jobs sonar jobs etc and (3) How many people will be using the dashboard?

Thanks much for quick response.
The details are as follows:
I am planning to host the dashboard in AWS using the Ubuntu for demonstration purposes.
(1) Currently we don't have git repositories, we will use svn ( 2 repositories) and tfs ( 2 large collections)
(2) We are around 100+ Jenkins jobs,  around 25+ SonarCube analysis jobs, around 20+ IBM Appscan jobs.
(3) At this point am not sure how many people were using the dashboard. But # will be quite high around 25+
(4) Also if you have any consolidated How to for hosting end-to-end application (with validation mechanism for each components) will be much helpful.

if you are hosting all of the layers of Hygieia on a single box with above mentioned load you are good in AWS with a m3-large. you should also be able to run collectors on the same box if you wish too.

Thanks all for your quick response.
I will start working on this and get back to you soon (Already started ad installed the DB, UI and API, working on setting up collectors).
Couple of things to update to the setup.md & api configuration file are

I was new to Mongo DB and I was executing the create user query with the results part and it was throwing error, It took me some time to get to that.
When trying to run api usin external property file, it was failing and trying to connect Mongo DB @port 11500 ( this was the default configuration in the git src code). Is it possible to update the properties to MongoDB defaults in the source code? If yes then please update the properties file.

@deepakasa It will be great if you can do a Pull Request with the setup.md etc changes that can help the other new users.

@deepakasa do a PR when you get a chance. Closing this for now.


Class 'AerialShip\SamlSPBundle\Entity\SSOState' does not exist

The bundle works fine for me with the deprecated SSOStateEntity, because Doctrine use annotations mapping by default.
When I try to use the non deprecated SSOState entity in Model folder, as I am using manual mapping, I configure a manual mapping to the xml mapping.
Then Doctrine raise an exception trying to find SSOState in "Entity" folder...
[Doctrine\Common\Persistence\Mapping\MappingException]
Class 'AerialShip\SamlSPBundle\Entity\SSOState' does not exist

My config.yml :

orm:
    auto_generate_proxy_classes: false
    entity_managers:
        default:
            auto_mapping: false
            mappings:
                SonataUserBundle: ~
                FOSUserBundle: ~
                FOSOAuthServerBundle: ~
                AerialShipSamlSPBundle:
                  type: xml
                  dir: Resources/config/doctrine-mapping

@vtexier I'm not sure where AerialShip\SamlSPBundle\Entity\SSOState came from. In doctrine-mapping/SSOState.orm.xml the class mapping is for is AerialShip\SamlSPBundle\Model\SSOState and it exists here. On the other hand deprecated Entity/SSOStateEntity extends mapped AerialShip\SamlSPBundle\Model\SSOState.
Can you check which version of the bundle you're using and where AerialShip\SamlSPBundle\Entity\SSOState came from?


Add support for exa

Exa is a pretty awesome tool which, in my opinion, has its place along with fd, bat and ripgrep. Adding its support would be pretty awesome !

nvm, I didn't see that the windows support is not yet available

nvm, I didn't see that the windows support is not yet available

You made me believe exa recently added Windows support until I opened this page :cry:


Fix up warnings and deprecations

ci check this

This did a bit more than just fix up warnings and deprecations - we are noticing different behavior for the check_certs playbook


iOS: Scrolling is slow during initial sync after adding account

My Feedbin account has a few hundred feeds. When I first set up the iOS app, and added my account, the initial sync took some time — which is totally expected. However, scrolling in the smart feeds was stuttery while the sync was going on. Something is periodically blocking the main thread. (I haven’t looked at the code yet and don’t have a theory.)

Syncing does a lot database queries and comparison work after getting the data from the sync service.  I have no doubt that is what is blocking the main thread.  I'm pretty sure that #913 is the same issue.
I recommend we move the sync code to a background thread so that it stops blocking the main thread.

With #913 it is at least partly just the fact that we do a sync (main-thread-blocking) fetch on changing selection. But it could be other things too.
I’ll take this one — I’ll do some profiling and then look at the code.

I think your latest performance tuning put this problem to bed.

After testing it some more it does look like there is a little bit of stutter while scrolling when sync is happening.

Got it. I’ll do some on-device profiling.

I think this problem is gone now.  I just tested with about 250 feeds.  I typically have to do around 100 paged requests for articles and process them.  Testing on my slowest device, my iPad, I didn't see any stuttering or lack of UI responsiveness while syncing my Feedbin account.
I think we can close this one out.

Awesome! We’ll file a new bug if this ever comes up again.


Add pulsar flink sink connector

@XiaoZYang introduces a module for a pulsar sink connector for flink. This PR is moving the work from flink repo to pulsar repo, so the flink connector can be released faster along with Pulsar releases.
Original Flink Github Issue: apache/flink#5845
Jira Issue: https://issues.apache.org/jira/browse/FLINK-9168
Original Author: @XiaoZYang (Zong Yang Xiao)

Created a master ticket for all the efforts related to flink connectors.

@aahmed-se : since we are moving other people's PR into pulsar's repo, it is important to mention the original work and credits to the original author @XiaoZYang .

retest this please

should be fixed

retest this please

run java8 tests

Looks like PulsarProduceMode.AT_LEAST_ONE is still incorrect (see https://github.com/apache/flink/pull/5845/files/fff36440197e3f34caf3af0b7ed7ba5320003e3b#r187084563)


[BUG] Footer doesn't follow the website theme in dark mode

Description
the footer doesn't follow the website's main color theme when in dark mode.
Expected behaviour
it should follow website color theme in both light and dark mode.
Screenshots/Video

Additional context
No response
What browser are you seeing the problem on?
Brave
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I will work on this issue (optional)
[X] I am a GSSoC'23 contributor

Its fine now...don't need to change