iso-image: Fix issues with GRUB

Tries to handle #123376
Things done
TODO

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[ ] Fits CONTRIBUTING.md.

The date issue is fixed, the one of failed theming is not. I can't commit on the resolution one since I don't have that.

@ncfavier Can you confirm the font problem is fixed? In that case we should merge a PR with either just the (hd0) → ($root) commit or that and the revert backed out and resolve the blocker.

Building the ISO now.
To be clear, ($root)/foo is the same as just /foo. I don't think we should merge this until we figure out a way to properly set the $root, which probably involves using the search command.

Well, that's just an issue of lacking theming, and the other commits prevent booting. Which is why, as I see it, the latter should prevent a release of 21.05 of while the former should not. This is why I'd like to separate the two parts and merge them separately, so we can take our time and find out how to solve the theming issue on all platforms without making @jonringer sad.

Fair enough.

without making @jonringer sad.

at this point, all software makes me sad

OK, I can confirm that this fixes the date bug and the resolution bug (at least on my machine).
d64034d5e79cf454a995d3270931d02c67287e0b and d64034d5e79cf454a995d3270931d02c67287e0b cancel each other out, so you might want to rebase them out.
For the record, here's a list of common VBE video modes.

Fix is still good after the force-push.

AFAIUI vbe is irrelevant here since we're in an UEFI gop driver.

From the manual:

Note that you can only use modes which your graphics card supports via VESA BIOS Extensions (VBE)

I have no idea though.

Yeah, GRUB's documentation is still heavily biased to their "legacy" program.
We're exclusively using the UEFI version of GRUB with the iso.

Aha you're right, videoinfo lists modes that aren't in that table.

haha! detecting as (hd0,msdos2) breaks themes here! An artificial reproducer!
So I guess the issue was that GRUB detected itself as (hd0,msdos2). (For the theme issue.)

The latest commit is unsuccessful in fixing the theming issue for me, in case that is what it is supposed to do.

@hyperfekt yeah, I pushed it eagerly, and then I figured out that reproduces the themeing issue.

I need to test on AArch64 still.

This is the one. Theming works now, and the date thing is still resolved. Good job!

awesome turn around. Thanks for working on this all :)

Verified with Tow-Boot on my Pinebook A64 that it works just as well as it did.

@GrahamcOfBorg test grub

This works for me, but only by accident: the nixos-installer-image marker file ends up on both (hd0) and (hd0,msdos2), so whichever GRUB tries first is picked. We should make sure to use a file that's only on (hd0).

It's not actually a different FS. It's isohybrid trickery.
We should look into why some files are not present.
But for the time being the failure state is seemingly lack of theme. Which isn't much of an issue as long as the user can boot in the system!

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/21-05-has-been-released/13407/5

Hi,
I have noticed that  iso-image plasma5-20.09.2538.0cfd08f4881-x86_64-linux.iso  probably lacks tools for dealing with fat32 filesystems. I had issues installing Nixos 21.05 on Samsung NP530U4E. System was damaged while upgrading from 20.03 to 21.05, giving the error "unable to build, disc was probably full" (quoting from memory, sorry). After trying to reinstall from USB got the same error message. Gparted was showing error message, that system lacks tools to deal with fat32 filesystems.I assume that  nixos-install was probably unable to detect fat32 boot partition and was assuming that disk is full. I was strictly following official manual for UEFI systems. I was able to install Nixos only after manual installation of mtools with nix-env -f '<nixpkgs>' -iA mtools. Just in case I have also declared mtools in configuration.nix

(I "moved" this comment into a new issue as it is irrelevant to this PR see #132094 )


chardriver upperCAN: support to independent set TX/RX FIFO size.

Summary
support to independent set TX/RX FIFO size
Impact
Testing

[Experimental Bot, please feedback here]
This PR summary is too short and lacks the necessary details for a proper review.
Here's a breakdown of what's missing and how to improve it:
Summary

Why is this change necessary?

Is it a fix for a bug?
Is it an optimization for performance?
Is it a new feature request?

What functional part of the code is being changed?

Be specific. Mention the driver, module, or subsystem affected.  For example: "This PR adds support to independently set TX/RX FIFO sizes for the UART driver."

How does the change exactly work?

Provide a technical explanation. For example:

"Two new configuration options are introduced to specify the desired FIFO sizes."
"The driver now allocates memory dynamically based on these configurations."

Related Issues:

Are there any related issues on the NuttX or NuttX Apps repositories? If so, provide links.

Impact
You need to address each point in the impact section:

New/Changed Feature:  YES - Briefly describe the new feature.
Impact on user: Likely YES - How will users interact with this new feature? Will they need to modify their configurations?
Impact on build: Possibly YES - Are there any new build options users need to be aware of?
Impact on hardware:  Possibly YES - Does this change affect specific architectures or boards?
Impact on documentation: YES - Documentation needs to be updated to explain the new feature and how to use it.
Impact on security: Maybe NO -  Consider if there are any security implications.
Impact on compatibility:  Possibly YES - Does this change break compatibility with any existing code or configurations?
Anything else to consider:  Mention any other noteworthy aspects of the change.

Testing

Provide more details:  List the specific operating systems, compilers, target architectures, boards, and configurations you tested on.
Show your logs:  Include relevant snippets from your testing logs that demonstrate the change's functionality both before and after the modification.

In short,  you need to expand each section of your PR with specific details about your changes to make it easier for reviewers to understand and approve.


Modify the password generation loop to generate passwords with increasing length for better security

changed the default values for the password generation algorithm to generate shorter passwords for better user experience
modify the password generation loop to generate passwords with increasing length for better security

This is a great idea, thank you!

Hi,
Yeah thanks it was fun. I was looking through my Alfred Workflows the last
couple of days, installed some new stuff. looked at Alfred World Clock that
I already installed months ago and found that it was missing UTC info I
thought would be handy and recently installed pwd which is cool but saw 5
random passwords being created and though let's customize this a little
bit and then realized you crafted this excellent piece as well.
Thanks for your useful and timesaving workflows.
I just finished a couple of workflows using nodejs.
Check them out if you have time:
https://github.com/Marcuzzz/joplin-alfred-workflow
https://github.com/Marcuzzz/visualcode-alfred-workflow
Cheers
On Sat, Nov 25, 2023, 13:29 Fede @.***> wrote:

This is a great idea, thank you!
—
Reply to this email directly, view it on GitHub
https://github.com/fedecalendino/alfred-pwd-gen/pull/3#issuecomment-1826297116,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYXV5XRNEFAQUX7TDVPEXDYGHQB5AVCNFSM6AAAAAA7Z7VZZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWGI4TOMJRGY
.
You are receiving this because you authored the thread.Message ID:
@.***>


rename Javascript => JavaScript

The language name is camel cased: JavaScript.

Good point.
Forgot to commit with fixes 1, but it's fixed. I'll retag and issue a new PR in a few. Trying to do this while on a conference call is making me sloppy.


Feature Request: A Popup Card

Hello,
First, I would like to thank you for your magnificent work.
It would be cool if you would create a button/entity type card that opens a pop up with a card in it. A card in where you can define one card that is shown if you click on this button/entity.

Duplicate of #56 , the reason of close with won't fix is given here: https://github.com/piitaya/lovelace-mushroom/issues/56#issuecomment-1031925191
I also close your issue, it won't come until a quiet long time. It rises too much questions and the easiest answer for this would be "take mushroom out of lovelace, create a standalone dashboard app like appdaemon with a dedicated configurator that uses HASS API and we're free to handle popup in an easy way for user", which is absolutely not what we want. It conflicts with our user-friendy non-negotiable prerequisite, even if it would be way easier for us on some points.


3.0 release

Changelog

Setup pre-commit hook using husky with lint-staged
Setup prettier using eslint-plugin-prettier with eslint-config-prettier
Run all files through prettier
Drop node 0.12 support, use typicode/please-upgrade-node for helpful message before exiting
Remove node-version-check from deps
Tweak eslint settings
ES6ify - () => {}, const/let , ${template} strings
createExplorer.js

Add func resolveDir to check if given path is a dir and return parent dir if not(sync or async mode supported).
Use the same identity func for both sync and async.

loadRc.js - Add func makeRcFileParser to create a rc file parser for the given parse func, extension and the next extension.
Remove object-assign from deps.
Move utility funcs statStubIsDirectory, makeReadFileSyncStub, assertSearchSequence,used for tests , to util.js
Migrate tests to jest

TODO

[x] pre-commit + lint-staged + prettier
[x] Drop node 0.12 support
[x] ES6ify
[x] Handle empty config file edge case
[x] Migrate tests to jest

Closes #71

@davidtheclark What should the behavior when consmiconfig gets an empty config file? Right now, the behavior is varied for different file formats and whether expected format was specified:

File format
Format Specified
Threw Error
Error Message

JSON
✘
✔
Error: Failed to parse

JSON
✓
✔
JSONError: No data, empty input

YAML
✘
✔
Error: Failed to parse

YAML
✓
✔
Error: Failed to parse

JS
✘
✔
Error: Failed to parse

JS
✓
❌
--

I think we should exit early with either an error or return null from loadDefinedFile>parseContent if content is falsy.

@sudo-suhas: These first two commits look good (ea485ed and 1f372ab). 82d5b79 does too much, though. I would have much preferred if the step of ES6ifying the code was a separate commit, because with all the formatting changes it's not possible review refactoring changes that you also made. If you're confident it's going to work fine, we can go with it — but I can't really review it.

What should the behavior when cosmiconfig gets an empty config file?

So the file exists but has no content. Your idea of adding a more friendly error message sounds good 👍 . I'd suggest separating it from this PR, since it's a new feature instead of a code style & convention update.

82d5b79 does too much, though.

I have split and rebased it into separate commits. While I am reasonable confident with the changes(tests passed), it would be better if it were reviewed as well.

I'd suggest separating it from this PR, since it's a new feature instead of a code style & convention update.

Technically this is a breaking change and that is why I brought it up here..

Thanks for splitting the commits! I'm going to ask that you split one more time, though, for safety. I think it's safer to refactor the code first without changing the tests, then refactor the tests without changing the code. That way you know you didn't introduce a bug in your code refactor that your test refactor swallowed. If we can do that, I'll be satisfied :)
All the changes look great!

Though it is unlikely to impact anyone, technically this is a breaking change and that is why I brought it up here..

Ah, yes. Makes sense.

I'm going to ask that you split one more time, though, for safety

Done 👍
Hopefully we can finish the rest of the refactoring by next week end.

@sudo-suhas: Excellent! The branch looks great so far.

I usually have the object-shorthand rule enabled in eslint. I didn't realise that this was supported in node 4. Unless you prefer to not use it, I'll squash this with the earlier commit refactor: ES6ify.

@davidtheclark, need a little help. I have migrated the test file successful-files.test.js to jest and I have introduced a couple of helpers to easily write tests without having to repeat code for sync and async. I have created a gist with the modified file - https://gist.github.com/sudo-suhas/3d84fa23ae4cba5700c916868fe7fa38. I want your opinion on this. Also, what do you think of using babel-jest?

@sudo-suhas: I'm not a big fan of the testResolves and testRejects helpers, because they obscure the procedure of the test so would make it more difficult to debug unexpected outcomes. I myself would prefer repeating the sync-async pattern.

Also, what do you think of using babel-jest?

My preference is to use the same syntax (and same linting) in the tests as in the codebase.

Alright. I tend to take the dedupe thing a bit too far sometimes 😅. Please don't mind but what do you think of a middle ground? A simple function which just calls the given test function once in sync and once in async.
function testSyncAndAsync(name, testFn) {
  describe('sync', () => {
    it(name, testFn(true));
  });

  describe('async', () => {
    it(name, testFn(false));
  });
}

The differences in sync and async mode could be handled using funcRunner in most cases.

:wave: @sudo-suhas sorry this feel off my radar. I was visiting extended family. I will look at it soon!

No problem at all 😄.

@sudo-suhas: Seems ok to me 👌 . Is there anything in particular you wanted me to look at?

Great. One of the things I wanted to know if you were okay with the helpers testSyncAndAsync and testFuncsRunner. Other than that, nothing in particular, but I value your opinion. So shall we release 3.0 then?

@sudo-suhas: Yeah, I'm a little wary of how much complexity there is in the tests now, making them more difficult to read and add to — but you've invested the time here, so if you think it's worthwhile, I'll take your word for it. Probably it makes plenty of sense after you write a few tests with the framework 👍
Am I right in thinking that 3.0 makes only one intentional change — introducing sync mode — but otherwise everything should work the same?

@davidtheclark I understand that we should strike the right balance wrt complexity and ease of writing a test(mainly repetition of similar steps). If you feel that we need to drop the helpers, I am more than willing to refactor all the required tests. Please take another look.
Actually, there are a couple of other changes as well. The most important of which is dropping support for node < 4. Additionally, an error will be thrown on encountering an empty config file.

Dropping support for Node 0.12 seems totally fine with me.
Also, I like the empty config file error.
Regarding test helpers — let's just go with what you wrote and see how it works! If we or contributors have problems with it, we can always refactor later. Does that sound good?

That sounds great 👍

Oooooooh, the latest Prettier releases uses cosmiconfig! https://github.com/prettier/prettier#configuration-file
That means we have another big user, like stylelint, that we probably should double-check against before releasing this branch, @sudo-suhas 😬

That.. is pretty cosmic 😁.
I remember we discussed integration tests. I had been meaning to ask you about it. So here's what I have so far. Use jest#mock to mock cosmiconfig and invoke prettier/stylelint programmatically. Either have a simple test to see that no errors are thrown or use snapshots to have a more through check. I don't really have any experience writing integration tests so I could use some help here.

@sudo-suhas A few thoughts came to mind about this branch:

Can we integrate Prettier with lint-staged instead of with the ESLint plugin? I really like that workflow, where you don't have to remember to format the files yourself.
I'm thinking maybe we should not start erroring when we find an empty config file. We could avoid this breaking change and leave that to the consumer: they can always decide whether to error or not. I just feel like it's an opinion that this module doesn't need to have.
If your method for automated integration tests with jest#mock works, that sounds like a great way to do it! I don't have experience testing this kind of thing, either — my default would just be to perform manual tests when I suspect danger.

Can we integrate Prettier with lint-staged instead of with the ESLint plugin? I really like that workflow, where you don't have to remember to format the files yourself.

I can do that, no problem. Though, even now, remembering to format is not required as this is taken care by eslint --fix in lint-staged but eslint will keep showing errors while in development if not formatted correctly. Another thing is that few of the eslint rules conflict with prettier formatting(arrow-parens, no-confusing-arrow). So I would prefer to extend eslint-config-prettier even if we remove eslint-plugin-prettier.

I'm thinking maybe we should not start erroring when we find an empty config file.

As you can see in https://github.com/davidtheclark/cosmiconfig/pull/78#issuecomment-318810892, we already throw errors for empty files in almost all cases. We would just be throwing a more accurate error instead of different ones for different file formats. Are you sure you want me to remove this check?

@sudo-suhas: Ok, good decisions 👍

@davidtheclark I have rebased and removed eslint-plugin-prettier in cad5e4f. lint-staged now uses prettier itself.  I also snuck in a minor improvement to funcRunner in 9d4f761 using reduce. Can you please merge this in? I'll tackle integration tests in a separate PR. That way, we can go ahead with #79 as well.

Merged!


Add timestamp to transactions

It would be nice to include the timestamp of a transaction when requesting the transaction list.
We could specifically use it in the /middleware/transactions/account/ endpoint to show the time of a transaction in the overview.

the only time i know is available for transactions of the same micro block is the micro block time.
I added that to my database.
If you don't mind you could test this server https://ae.criesca.net:3011/middleware/transactions/account/ak_nv5B93FPzRHrGNmMdTDfGdd5xGZvep3MVSpJqzcQmMp59bBCv?limit=10&page=1 to see if my deployment is compatible to aepp-middlerware?

@johnsnewby we need this feature in Base app as well

@kryztoval that looks fine to me. Would be amazing if this could be included. It is part of the https://github.com/kryztoval/aepp-middleware-mn port of the middleware.

To be included in this you need to talk to @johnsnewby 😄

@johnsnewby we have gotten more requests from users for this specific feature. Is there anything blocking this issue?

Hello, only time. I'll do it now, so it gets into the next release.

Looking forward to it! :)

didn't it already implemented? can we close this issue?

Yes, this has already been implemented.
During the vote I noticed that the new endpoint /from/<fromAddress>/to/<toAddress>/ (not sure exactly how the endpoint was) did not include the timestamp. Maybe that's something that can be added as well.

OK the problem here is that the transaction type that the node provides does not include a time field and I have made various structs which mirror the node's types--so putting time into transactions all over the place will make these diverge. I don't have a massive problem with that but it changes lots of things, and I don't want to just do it without thinking about the consequences.
So as things stand, also in the node, transactions do not have timestamps, they are included in micro blocks which do. I would much prefer endpoints which embody this fact, rather then returning objects which look like transactions but include extra information. OTOH the information is meant to be useful, so I don't want to be too hardline, either.
Ideas would be super welcome :)

What I did was I timestamped all the transactions inside a micro block with the micro block's timestamp, not perfect, but at least gives you a timestamp that is 3 seconds more or 3 seconds less from the real time it happened at.
What do you think about that?

I understand your concerns and as always, there is probably no solution that is perfect... I see 3 possible solutions:

Change the type of the struct that is used by the middleware, which means additional data (eg. timestamps for transactions) are available everywhere.
Advantage: Ease of use.
Disadvantage: Different structure than the node endpoints.

Return the same structure as the node and let the users of the middleware fetch the additional data themselves.
Advantage: Structure is in line with node.
Disadvantage: Additional effort required by developers.

Some kind of hybrid approach. This could either be done by creating a new endpoint (eg. /getTransactionTimes/?hashes=<txHash>,<txHash>, which would then return an array of timestamps. Or we could include additional metadata that is specific to the middleware (eg. { ...transactionDataWithNodeStructure, middlewareData: { timestamp: number }.
Advantage: Structure is mostly in line with node, easy to use for developers.
Disadvantage: Seems kind of hacky.

My vote goes towards number one. I don't know what implications it has, but I could live with the fact that the middleware returns data that is different from the data that the node returns. After all, that's what the middleware is made for - giving us features that the node does not provide.


Updating the requirement for numpy

Purpose
Updates requirement.txt to let numpy be >= 1.19.1
Tested for issues
Related issues
#3105 #3103
Future Lookouts
quimb imports from numpy.matlib , it is deprecated since numpy 1.19.0

Friendly ping @exAClior - did you have time to look into the flakes?

@balopat  terribly sorry, I was very occupied with other things  since it is the beginning of the semester. Maybe I could find sometime to work on that in the next few days or is there anyone willing to take on this?

@balopat terribly sorry, I was very occupied with other things since it is the beginning of the semester. Maybe I could find sometime to work on that in the next few days or is there anyone willing to take on this?

Absolutely no worries - I'd suggest closing this PR in the meantime. I will pick this up myself or find someone in the team :)


Releasing and Packaging

A big part in making Rust more attractive for ROS2 community and vice versa would be in providing released packages, making rclrs (or portions of) more readable installable. As may ROS users may be unfamiliar with Rust, given ROS's legacy with C++ and Python, simplifying installation could help lower the barrier and learning curve. Ideally, it would be nice to see rclrs as easy to include as an external crate, just as relying upon any other package released on crates.io , but I'd also be happy if debians could be shipped via synced ROS2 releases.

I think this can be closed now since rclrs is available on crates.io.
There is also discussion about adding it to the core ROS 2 distribution, but that's probably better tracked elsewhere (REPs or so) than here: https://discourse.ros.org/t/process-for-third-party-client-libraries-to-be-incorporated-into-the-core-ros-2-distribution/27325/23


Update git-in-here.yml

This contribution marks the start of my entry 'git'-ing into open source.
PR Type: Name addition
Affiliation: N/A
Ticket: N/A
Checklist:

[X] I've read Contributing Guidelines
[X] I agree to follow the Code of Conduct

Please Add the hacktoberfest-accepted label. Thank You!

@Lissy93  Please Review the PR. This is my first PR. Please accept it.

Looks like you've updated the indentation of the whole file, can you undo those changes as it'll otherwise cause conflicts with the other PRs. Thanks :)


Fix map, filter etc. break maxBy, minBy?

Adds array/object and index/key arguments to map, filter etc. iteratee functions. Side effect: maxBy and minBy also have array/object and index/key arguments.

Thanks but this by design as those who dig functional sugar don't dig the extra arguments because they make composition harder.

Gotcha, figured there was probably a good reason. Definitely agree that being able to access and mutate  the array/object is probably a bad idea. Is the same true for index/key though? Say I wanted to do something like multiple an array of numbers by each number's index. What would be best practice using lodash-fp? E.g. in OCaml you could do something like List.mapi (fun n i -> n * i) [1;2;3]

Is the same true for index/key though?

Ya it causes issues to. For example:
['6', '8', '10'].map(parseInt);
// => [6, NaN, 2]

because parseInt accepts a second param, radix, which is getting set as the index value.

Say I wanted to do something like multiple an array of numbers by each number's index.

You can still use the chaining API:
_(array).map(...).value();


Minitest/TestFileName errors on empty files

Expected behavior
No failures when analyzing empty files (or files with only comments)
Actual behavior
Minitest/TestFileName errors:
An error occurred while Minitest/TestFileName cop was inspecting /Users/michael.overmeyer/src/github.com/Shopify/shopify-i18n/test/empty.rb.

Running with -d flag to get additional output:

Full stack trace
rubocop -d --only=Minitest/TestFileName test/empty.rb
For /Users/michael.overmeyer/src/github.com/<redacted>: configuration from /Users/michael.overmeyer/src/github.com/<redacted>/.rubocop.yml
configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-minitest-0.26.0/config/default.yml
configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-minitest-0.26.0/config/default.yml
Default configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/config/default.yml
configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-performance-1.15.2/config/default.yml
configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-performance-1.15.2/config/default.yml
configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-rake-0.6.0/config/default.yml
configuration from /Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-rake-0.6.0/config/default.yml
Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /Users/michael.overmeyer/src/github.com/<redacted>/test/empty.rb
An error occurred while Minitest/TestFileName cop was inspecting /Users/michael.overmeyer/src/github.com/<redacted>/test/empty.rb.
undefined method `class_type?' for nil:NilClass

          return true if node.class_type? && test_class?(node)
                             ^^^^^^^^^^^^
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-minitest-0.26.0/lib/rubocop/cop/minitest/test_file_name.rb:32:in `test_file?'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-minitest-0.26.0/lib/rubocop/cop/minitest/test_file_name.rb:24:in `on_new_investigation'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/commissioner.rb:154:in `block (2 levels) in invoke'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/commissioner.rb:165:in `with_cop_error_handling'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/commissioner.rb:154:in `block in invoke'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/commissioner.rb:154:in `each'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/commissioner.rb:154:in `invoke'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/commissioner.rb:84:in `investigate'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/team.rb:154:in `investigate_partial'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cop/team.rb:97:in `investigate'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:322:in `inspect_file'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:266:in `block in do_inspection_loop'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:300:in `block in iterate_until_no_changes'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:293:in `loop'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:293:in `iterate_until_no_changes'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:262:in `do_inspection_loop'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:143:in `block in file_offenses'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:168:in `file_offense_cache'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:142:in `file_offenses'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:133:in `process_file'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:114:in `block in each_inspected_file'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:113:in `each'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:113:in `reduce'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:113:in `each_inspected_file'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:99:in `inspect_files'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/runner.rb:52:in `run'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli/command.rb:11:in `run'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli/environment.rb:18:in `run'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli.rb:72:in `run_command'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli.rb:79:in `execute_runners'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/lib/rubocop/cli.rb:48:in `run'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/exe/rubocop:19:in `block in <top (required)>'
/opt/rubies/3.1.2/lib/ruby/3.1.0/benchmark.rb:311:in `realtime'
/Users/michael.overmeyer/.gem/ruby/3.1.2/gems/rubocop-1.43.0/exe/rubocop:19:in `<top (required)>'
/Users/michael.overmeyer/.gem/ruby/3.1.2/bin/rubocop:25:in `load'
/Users/michael.overmeyer/.gem/ruby/3.1.2/bin/rubocop:25:in `<main>'
.

1 file inspected, no offenses detected

1 error occurred:
An error occurred while Minitest/TestFileName cop was inspecting /Users/michael.overmeyer/src/github.com/<redacted>/test/empty.rb.
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.43.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.24.1, running on ruby 3.1.2) [arm64-darwin21]
Finished in 0.21253699995577335 seconds

Describe here what actually happened.
Steps to reproduce the problem
mkdir test
touch test/empty.rb
rubocop --only=Minitest/TestFileName test/empty.rb
# Fails

echo "# Just a comment" > test/comment.rb
rubocop --only=Minitest/TestFileName test/comment.rb
# Also fails

RuboCop version
1.43.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.24.1, running on ruby 3.1.2) [arm64-darwin21]
  - rubocop-minitest 0.26.0
  - rubocop-performance 1.15.2
  - rubocop-rake 0.6.0

This issue is a dup with #225 and fixed by #227. I will release later.

FYI, RuboCop Minitest 0.26.1 has been released:
https://github.com/rubocop/rubocop-minitest/releases/tag/v0.26.1


I am unable to download the sample data. Server not responding.

The server not responding to the bag file download. Any alternative sample bag file data link? Thanks!

Looks like example 1 & 2 are no longer available. Example 3 is still available, but it is a significant amount of data to download.
I downloaded the third dateset and could not get it working.

I still can’t download the sample files. Can I open the server for downloading?

I still cannot download either.


verify_boot_error_warnings refactor to use dmesg filters

Break up test into syslog and dmesg flavors to split results by severity
Add Dmesg tool option to filter by log level and facility
refactor ignore line filtering into it's own shared function

@LiliDeng can you check if the change is worth to be merged?


Sharing: Literate programming - Expanded the discussion on Quarto

Hi, all:
As previously discussed and suggested, please review this PR for an expanded discussion on Quarto in Sharing.
Thanks for your consideration.
SR

@adrhill feedback has been incorporated

Thanks!


Fixes for Dart2

Ask first. We try to avoid publishing -dev releases, etc.
On Wed, Jul 11, 2018 at 1:26 PM Ben Konyi<EMAIL_ADDRESS>wrote:

The version is 0.1.2-dev as of this PR, so I published with that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sync_http/pull/6#issuecomment-404298882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABCimHp6M1mlc4E0wP8FVPocbBw5K6Qks5uFl9tgaJpZM4VLqG6
.


Account summary - notifications - unsigned orders modal

There is no feedback after tapping 'claim', we can use the 'pending' tag here
Market title isn't clickable through the market page
Total gas is showing as zero

@cillianhunter0 what should the feedback when user clicks submit?

We'll work the user feedback mech when design is worked out.

putting this back in feedback until we get the design worked out for handling user feedback.

@cillianhunter0 please review


Extended sd wire usage documentation

SD-WIRE usage validation documentation has been extended by adding commands to check and install all libraries and tools which are required to install SD-MUX

@sulewskiprzemyslaw Overall, I'm still missing one procedure for validation, right now we have: 1. First use, 2. Everyday scenario, 3. Scenario with RTE, 4. Presale validation. Imo you should try to merge the steps from 1 and 4 into one guide. Points 2 and 4 should be reconsidered, maybe this will be a subsection needed etc.


Better default webpack config

Hello,
I just ran npm run build and saw that the resulting CSS file is not minified. So I looked at @phenomic/plugin-bundler-webpack default webpack config file and effectively, css-loader's minimize option is not used at all.
Is this intentional or is it really missing ? If it is missing, I can propose a PR to fix it :)

In fact the default config is probably not good enough.
We should replace this one somehow by grabbing the one from CRA (via react-scripts https://github.com/facebookincubator/create-react-app/tree/9af042263f7c6e66b4c1402d2f6fc81250c6ce97/packages/react-scripts/config)
See #1190 and #1200 for more info.

PR welcome as it should not be that hard to get the config from
react-script (via import/require) and merge it using spread operator and the things we need if relevant (hot loading probably?)

Just to be sure that I understand what you want to achieve : the idea is to add react-scripts to @phenomic/plugin-bundler-webpack dependencies, then import its webpack configs (depending on the NODE_ENV and PHENOMIC_ENV) and maybe override some stuff ?

Exactly! Can feel weird in the first place, but for now it's for us the simplest way to rely on a good (and up to date) common config widely used (and so accepted)!
This might be revisited later, but for now, it's for us a good way to not spend time on creating a config to make everyone happy.

OK I will try to work on that :) Thank you for the tips

If you need anything, just ask!

I see that the project uses Lerna. To add a dependency on a particular package, do you use lerna add module --scope=package or directly yarn add module in the directory of the package ?

To be honest I don't use any of this solution. I add the dep by hand in the package.json of the relevant package.json and then I do yarn at the root of the repo :D

Ok so I guess you don't really care how I install react-scripts

As you wish. Should be the same at the end anyway.

I looked at it, began to work on a solution (using webpack-merge) and I have some questions :

how can I override this loader configuration specifically ? I don't want to touch others, but for this one I need to use @phenomic/babel-preset and react-hot-loader/babel plugin. The only way I think about to override it is to override all the module.rules array, but it is dumb because we would lost react-scripts configuration here
I have the same issue with the ExtractTextPlugin configuration : we want to disable it when process.env.PHENOMIC_ENV !== "static", but I can't figure how to override react-scripts's configuration for it. Same as above, I can override the whole configuration, but will lose the defaults in that case

I think that react-scripts webpack configuration is pretty good, but rely on create-react-app custom stuff that is not necessary in phenomic. Maybe we could write our custom configuration that would be heavily inspired by react-scripts one, but not directly import it and override it. What do you think about it ? From my point of view, it doesn't seem to be more work than override everything.

I guess we should not use wepack-merge and do the merge by hand. Should not be hard imo.
We can probably loop on rules and use test.toString() to see the regex for the js(x) loader (but we should merge with eslint-loader as it's used (imo) in a safe maner.
For ExtractTextPlugin it's easy, loop + instanceof (as we have a "new" ^^). I had do did this in previous version of phenomic.
I understand your point, but my idea is to rely on the package so we can (in theory) easily upgrade. And say "we rely on this". People will trust this more than a copy/adapted :)

I see. Instead of trying to deep merge react-scripts config + current phenomic config, I should handpick what's interesting in react-scripts config (particularly loaders).

Closing due to lack of interest. My idea is really to have a minimal config that people should extends by themselves if they want to. Might revisit later.


Update links in README.md

updated the links to the book to the documentation

bors r+
Thanks!

bors r+
Thanks!


iroh p2p id command

ipfs id
returns a JSON data structure which contains a bunch of pieces of information:

id
publicKey
addresses
agent version (kubo version)
protocol version (ipfs/0.1.0)
protocols (a whole host of versions)

It strikes me there's a lot of overlap with #267
What's also interesting is that this command, suddenly, returns pretty-printed JSON. Do we want to do that? Or do we want to take a more structured approach to JSON support and go for a text-based structure ala:
agent_version = "iroh/0.1"
protocol_version = "ipfs/0.1.0"

instead and have a --json option that consistently produces JSON output (turning off progress bars for add and get too)?

The iroh p2p id command needs to report:

its peer id
addresses of peers it knows about
various protocol version, including the ipfs version

Anything I missed?

the more I think about it, the more this is all just a bad pattern to follow. I like the look of https://github.com/mxinden/libp2p-lookup a lot more, and find the tool generally more useful than what IPFS id does, both in terms of what and how it's reported.
A few adjustments for our context:

I see no reason to separate dht and direct into different subcommands. I'd much rather try to parse a multiaddr first, dial that on successful parsing, then fall back to trying to parse a PeerID, using the DHT when a PeerID is given. Maybe there's some nuance I'm missing, but I doubt it given this is how kubo works.

no need for a --network flag, just used the configured network.

Is there any reason why a separate ipfs p2p id command is needed? In Kubo, ipfs id would return your node's info, but ipfs id PeerID returns the same info for a different node

@winterhuman I think it's under p2p because it won't work without a p2p node running, and we envision configurations without a p2p node with iroh cloud. Is that correct, @b5?

@Winterhuman I think it's under p2p because it won't work without a p2p node running, and we envision configurations without a p2p node with iroh cloud. Is that correct, @b5?

No. There will be no iroh id top level command. Instead we're moving it down into p2p, which will work either offline or online. In the offline context, I expect the command to behave like https://github.com/mxinden/libp2p-lookup , which queries the DHT, attempts to dial the peer, then closes after receiving a response from the identify protocol.
Running iroh p2p id without any id should default to the node's own Peer ID. This lookup again should work both offline and online, but in both context will not need to make any network calls, and simply return the values that would be supplied as a response to an identify protocol request

Is <addr> optional for iroh p2p lookup so that you can get the information for the node you're connected to? If not, how do you start getting your peer id or address so you can do a lookup for yourself?

I think yes, no <addr> means grabbing your local information. Should be added to the documentation.

closed by #372


stuck di buton telegram ketika mau buy

raceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/aiogram/dispatcher/dispatcher.py", line 415, in _process_polling_updates
    for responses in itertools.chain.from_iterable(await self.process_updates(updates, fast)):
  File "/usr/local/lib/python3.10/dist-packages/aiogram/dispatcher/dispatcher.py", line 235, in process_updates
    return await asyncio.gather(*tasks)
  File "/usr/local/lib/python3.10/dist-packages/aiogram/dispatcher/handler.py", line 117, in notify
    response = await handler_obj.handler(*args, **partial_data)
  File "/usr/local/lib/python3.10/dist-packages/aiogram/dispatcher/dispatcher.py", line 283, in process_update
    return await self.callback_query_handlers.notify(update.callback_query)
  File "/usr/local/lib/python3.10/dist-packages/aiogram/dispatcher/handler.py", line 117, in notify
    response = await handler_obj.handler(*args, **partial_data)
  File "/root/c9sdk/smshub_aiogram_light/telegram/bot.py", line 90, in process_service_choice
    check_balance = float(await hub.get_balance())
ValueError: could not convert string to float: ''

BAD_KEY, smshub api key salah


Folder level permission check in Ranger

changes bucket path naming to hdfs style with fqn (starting with / etc.)
Adds option to check full s3 path in Ranger

Codecov Report

Merging #22 into master will decrease coverage by 0.47%.
The diff coverage is 76.47%.

@@            Coverage Diff             @@
##           master      #22      +/-   ##
==========================================
- Coverage   86.16%   85.68%   -0.48%
==========================================
  Files          29       29
  Lines         571      580       +9
  Branches       51       56       +5
==========================================
+ Hits          492      497       +5
- Misses         79       83       +4

Impacted Files
Coverage Δ

...k/proxy/provider/AuthorizationProviderRanger.scala
100% <100%> (ø)
:arrow_up:

...la/com/ing/wbaa/airlock/proxy/data/S3Request.scala
100% <100%> (ø)
:arrow_up:

.../airlock/proxy/api/directive/ProxyDirectives.scala
86.79% <42.85%> (-6.83%)
:arrow_down:

Continue to review full report at Codecov.

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


Fuzz proposal: fuzz target for formatting

Hi, Would be interested in  a fuzz target that formates the code twice and checks for inconsistencies between them, something which is done here:
https://github.com/astral-sh/ruff/blob/c944d23053fe84e63a7515c75a50ce46b63dc2e0/crates/ruff_python_formatter/tests/fixtures.rs#L213
For example something like this:
#![no_main]

use libfuzzer_sys::{fuzz_target, Corpus};
use ruff_python_formatter::{format_module_source, PyFormatOptions};
use similar::TextDiff;

fn assert_difference(formatted: &str, reformatted: &str) {
    if reformatted != formatted {
        let diff = TextDiff::from_lines(formatted, reformatted)
            .unified_diff()
            .header("Formatted once", "Formatted twice")
            .to_string();
        panic!(
            r#"Reformatting the formatted code a second time resulted in formatting changes.
---
{diff}---

Formatted once:
---
{formatted}---

Formatted twice:
---
{reformatted}---"#,);
    }
}

fn do_fuzz(case: &[u8]) -> Corpus {
    // throw away inputs which aren't utf-8
    let Ok(code) = std::str::from_utf8(case) else {
        return Corpus::Reject;
    };

    // format code twice
    let formatted = match format_module_source(code, PyFormatOptions::default()) {
        Ok(formatted) => formatted,
        Err(_) => return Corpus::Reject,
    };

    let reformatted = match format_module_source(formatted.as_code(), PyFormatOptions::default()) {
        Ok(reformatted) => reformatted,
        Err(_) => return Corpus::Reject,
    };

    assert_difference(formatted.as_code(), reformatted.as_code());

    Corpus::Keep
}

fuzz_target!(|case: &[u8]| -> Corpus { do_fuzz(case) });

@qarmin did some fuzzing of the formatter in the past. See https://github.com/astral-sh/ruff/issues/7433
I don't know if the script they used is available somewhere.
Overall,  we've found fuzzing a useful tool to improve Ruff's stability and it helped us find many stability issues before releasing ruff's formatter. However, fuzzers also discover issues that are very rare or close to non-existent in practice. That's why reporting and fixing all of them isn't necessary impactful for our users and is the reason why we prioritize real-world issues or new features over fuzzer issues (but this depends on the fuzzer issue).
What's most helpful for us is a list of triaged fuzzer issues. But I think triaging is hard to impossible without understanding how our formatter works. Having a way to run the fuzzer (by someone who can triage issues but doesn't know how fuzzing works) could, therefore, be helpful, if we can integrate it into our exsiting fuzzer infrastructure (see fuzzer directory).

Yeah, go for it if you're interested in adding it to our existing fuzzer.

Was this ever added? Formatter idempotency has proven to be super useful for bug detection in other projects (see @jasikpark's work with Prettier, my work with boa and Biome).

@manunio: I think your fuzzer is a good start here, but the reformatting should never fail (instead should panic!) as we have a safety guarantee from the formatter to produce valid syntax. Do you want to open a PR? We can discuss further changes there.

I slept on it; I actually think both this and a format validity fuzzer which fuzzes to check that the formatter does not introduce linter errors would be good to add.

This sounds interesting. Especially to discover incompatibilities that aren't obvious. Although we may need to have a ignore list of rules that we know are not compatible.

Was this ever added? Formatter idempotency has proven to be super useful for bug detection in other projects (see @jasikpark's work with Prettier, my work with boa and Biome).

Honestly, I'm not sure but I think it would be valuable to have.


CIP-0129? | Governance Identifiers

Introduces byte representation along with a bech32 prefixes for different Conway era credentials and identifiers.
This PR includes relevant updates to CIP - 0005, and 0105 (including updated test vector)

(rendered proposal)

Once this is merged, We would begin work for supporting it for CNTools and Koios API

SPO Scripts can support it too. But CLI and DB-Sync must also be onboard. For HW-Wallets, such a change will most likely not be implemented until the end of the year, the release cycle from the vendors (not the devs) is horribly slow nowadays.

@rphair updated the PR with the implementation plan, please provide context/recommendation for acceptance criteria.

good stuff, AdaStat will definitely support this CIP

Id suggest we move to make this standard an "extension" to CIP105, so that it optionally adds to the existing standard, in a backwards compatible way

After extensive discussions on CIP105, it was determined that this specification should be its own CIP, as it is not related to CIP105 (which specifies the derivation for new Conway era keys). Confusing this CIP as a backward-compatible extension of CIP105 is a mistake. This CIP establishes a new specification for various Conway era credentials generated using CIP105.

I believe at this stage of maturity for governance tooling having competing standards might not be ideal, potentially damaging user experience and compatibility.

As specified in the CIP, no existing toolings need to do extensive work to support this CIP, they would only have to switch to a proper bech32 prefix. I do not believe it is too much work just to replace drep -> drep_vkh for existing tools. I wouldn't want to create so much chaos but the suggested new prefix aligns with the specification of the CIP105 itself.

I believe at this stage of maturity for governance tooling having competing standards might not be ideal, potentially damaging user experience and compatibility.
I am worried that we reach the Chang hardfork (estimated end of August) and half of tooling represents DRep IDs one way and the other half of tooling represents it another way.

If this has to go through, sooner the better, to prevent the exact scenario mentioned. Currently the support for conway across tooling is a bit premature, with all exploration of edge cases requiring frequent fixes/changes. More mature the tooling becomes, more resistance there would be for changes later on.

@ashisherc

After extensive discussions on CIP105, it was determined that this specification should be its own CIP, as it is not related to CIP105 (which specifies the derivation for new Conway era keys). Confusing this CIP as a backward-compatible extension of CIP105 is a mistake. This CIP establishes a new specification for various Conway era credentials generated using CIP105.

Sorry, I wasn't clear what I meant by "extension", my bad.
I didn't mean that this shouldn't be its own proposal,
I meant that this proposal could be backwards compatible with CIP105, building on top of the existing standard directly.

I do not believe it is too much work just to replace drep -> drep_vkh for existing tools. I wouldn't want to create so much chaos but the suggested new prefix aligns with the specification of the CIP105 itself.

Would also need changes for tools who have implemented DRep scripts and CC key/script credentials,
although, point taken this isn't a massive lift.
There is a danger here of some tools who have implemented CIP105 not seeing these changes,
resulting in their tooling being broken.
I do worry about this,
we have seen this a few times in CIPs.

@rdlrt

If this has to go through,

This is a tricky one,
I would say it is up to the community to decide the necessarily
Personally, I think these changes do bring value
but I also see risk of them, as described

sooner the better, to prevent the exact scenario mentioned.

This is a good point, I agree.

@Ryun1

There is a danger here of some tools who have implemented CIP105 not seeing these changes, resulting in their tooling being broken.

This is part of upgrades, its like not upgrading to Chang bcoz existing dApps may not notice new changes. I know this is an exaggeration but the point is there are very limited no of tools that deal with drep/cchot/cccold key generation. Once this CIP is merged, we can do the needful to reach out to these tools and request for upgrades. Most of the tools which will support Chang upgrade are already listed in the acceptance criteria. We will also be linking to this CIP from Cardanoscan so that devs can easily find the spec used by us for generating drep and other IDs.

HW-Wallet changes will take a longer time, not sure how to deal with it in the meantime. Because with the SPO Scripts, i always show the same data on screen like bech32 representations as it appears on the HW-Wallet gui. If those two differ, thats a problem.

@gitmachtl added some details in the implementation plan for this. During the migration period, the software UI can show both the formats with a slightly greyed out font/color mentioning deprecated format. Essentially informing user to refer it for verifying on a HW wallet.

(comments from me and David Misiak for VL)
It's not great that the drep prefix will change its meaning.
Where is a DRep to be used in the form of whole drep credential, and where we should show drep_vkh instead? If one tool (e.g. a SW wallet) uses one representation, but another tool (e.g. a HW wallet) the other, it is confusing for the user at best --- one would be unable to compare the displayed data (to some extent --- the bytestrings encoded into bech32 will overlap). For instance, when ones has a script drep, should drep_script or drep (with the "script" type encoded in the subsequent bytestring) prefix should be used? This CIP should give unambiguous guidelines for UI design.
The design in the proposed form is not coherent; it's inspired by addresses, but that's kind of a bad analogy; addresses are tied to network and serve a different purpose.
An already identified problem is that Cardano has no consistent notion of a "key / key hash / credential" object.
It transpires for instance in the "address" field in CIP-8 (message signing) where one wants to put in addr key hash, but instead a whole address goes in (i.e. one extra byte for address header + key hash), but for DRep key, only a key hash is used currently (i.e. no extra header byte). It would make sense to unify it all, but the proposed CIP does not do it (it ignores credentials from staking and multisig keys etc.). It also introduces unsystematic coupling ("We reserve the values 0 and 1, as these are used in the Cardano Address Network tag") --- if someone in the future adds another value for network tag (say, another specific kind of testnet), it could clash with this CIP.
I'd say that DApps / script authors / UI developers would welcome if Cardano had a unified notion of credential, which would cover all possible key hashes and script hashes, also those potentially added in the future, and a standardized way of displaying it (here I'd be happier with more than 16 possibilities as is currently suggested in the CIP by reserving just 4 bits). So this CIP might want to address not just drep and cc keys, but cover payment and stake keys, too. I have not thought it through at all, though, so I am not sure it is possible to design it in an easily implementable fashion.
hw-cli is not mentioned in the "path to active" list (maybe not affected? --- it does not do UI, but some command line arguments perhaps? but at least new version of ledgerjs/trezor connect would likely be required).

FYI - This is now being used in Koios

@rdlrt thanks for following up on https://github.com/cardano-foundation/CIPs/pull/857#issuecomment-2264592368 (I'm noting this to help editors stay abreast of current implementations)

I can also add that Eternl will make this change, to be applied in next update.
Not that affected like other tools might be but it will display CIP-129 id in UI but take any of the versions as input. So if you grab old style id from some other source to delegate to within Eternl, it should still handle it and extract hash correctly.

But CLI and DB-Sync must also be onboard.

I'm just seeing this CIP and I'm not a fan (at this point) because we are now straying from the CDDL. We've been down this road before in cardano-api and it caused confusion because we had an "intermediate tx body format" that differed from the ledger's CDDL.
Why do we need a header when we can piggy back on bech32 i.e https://github.com/cardano-foundation/CIPs/tree/master/CIP-0105?. I know this describes wallet derivation however it introduces new prefixes for the governance credentials.
I can get behind this CIP (or some iteration of it) if the intention was to make it part of the CDDL. However, this route will require input from the ledger team.

@WhatisRT @lehins in light of @Jimbo4350's https://github.com/cardano-foundation/CIPs/pull/857#issuecomment-2356924249 please review & post here so we can remain aware of whatever Ledger impact there would be for this CIP.

https://github.com/IntersectMBO/cardano-ledger/issues/4441 some decisions were taken without considering future implications. this CIP does solve a few things, and major things for ecosystem tooling.

The CIP was created well prior the date of the fork (we still had to have a date for fork on preprod) , if any chance was present to put it to ledger,  it'd have been at the time - I assume the suggestion from Jordan above is a bit more sarcastic way to say it wont be done (as now it not only will have a fork requirement, but will also make things muddy between pre/post fork) 🙂
Having said that, for tooling - this did not even require dbsync/CLI/ledger to adopt.. since bech32 representation is best rendered on client-side.
I usually keep my expectation bar very low for any changes upstream due to the complicated jungle it has become - so the only question is , whether the builder/tooling community have an expectation to continue down this route, in spite of conflict - and how can we move forward (to get to approve/reject/modify stage)

this CIP is more on the frontend/tooling/user side imo. ledger stores it already differently for drep key hashes and drep script hashes. tooling/explorers/etc have already jumped on it because we saw the first issue on chain that people have used the wrong bech representation for a drep script. on the CLI side, we have the keyHash/scriptHash in the queries. there is not a single output that is showing a bech representation. so i don't see an issue here atm.

But CLI and DB-Sync must also be onboard.

After months now implementing this on the tooling side, i don't see the need for a change on cardano-cli output side atm. We have the different outputs for keyHash/scriptHash. If it would be changed, than we would need to totally flatten it and only have a single Hash format with the infobyte infront. But it could be added for the input parameter option on cardano-cli, that would be not a different task for cardano-cli to recognize hashes and bechstrings that are that 1 byte longer and handle it internally to use it as a drep keyHash or scriptHash.

the same for db-sync. especially considering there are conversations going on now to remove the text (bech32) representations from tables, and leave only binary data

As pointed out by previous comments, there is nothing do to for ledger with this CIP. Any tooling could support this CIP tomorrow without a HF.
I agree with the sentiment that the CDDL is suboptimal for this purpose, and I'm supportive of @ashisherc's opinion that it might have been better to not inline the definitions to save a few bytes. We have no idea how much votes we'll actually get, it seems like a premature optimization to me. But it's done now, and the only way to change it would be community feedback.

@WhatisRT @lehins in light of @Jimbo4350's https://github.com/cardano-foundation/CIPs/pull/857#issuecomment-2356924249 please review & post here so we can remain aware of whatever Ledger impact there would be for this CIP.

This CIP describes textual representation of hashes used in transactions. In CBOR we store hashes in binary format, so textual prefixes or any other offline representation (like bech32) have no business being encoded in the on-chain data.

.. I'm supportive of @ashisherc's opinion that it might have been better to not inline the definitions to save a few bytes.

When choosing between two legal isomorphic representations in the binary format we'll almost always choose the more efficient one. CBOR is meant to be decoded by tools, not read by people, so for any decent programmer it should not make any difference on how the data is encoded as long as it is clear how to decode it and CDDL spec describes it unambiguously. Binary represntation needs to be compact and efficient, it does need to be pretty. We will have millions of votes and these few bytes savings will manifest in megabytes of savings in the on chain data. So, @ashisherc and @WhatisRT I respectfully disagree with both of you.
My take on this CIP is that has nothing to do with Ledger or CDDL. This is 100% tooling issue.

@lehins thanks for your valuable inputs
Clarification—This CIP's goal was never to change the CDDL or ledger spec. It has always been an off-chain spec for byte representation and bech32 encoding for various government-related credentials and identifiers. We just realized that this spec may also be helpful at the ledger level.
Since you mentioned the storage efficiency, it has been long exploited by tx metadata, it is irrelevant I know. But let us see the existing CDDL for the gov credentials itself,
Gov Action ID - https://github.com/IntersectMBO/cardano-ledger/blob/a44a5b5ac9f68c5d7a2ff38b040a5fcac8ccfc6a/eras/conway/impl/cddl-files/conway.cddl#L148
Instead of having a list of tx ID, and index bytes, it should bring efficiency by just using this CIP action ID, since you mention there will be millions of votes, and each vote will also have an action ID. Exactly same data structure even for various voters.
DREP/CC Credentials https://github.com/IntersectMBO/cardano-ledger/blob/a44a5b5ac9f68c5d7a2ff38b040a5fcac8ccfc6a/eras/conway/impl/cddl-files/conway.cddl#L338
Storage efficiency is also impacted if we keep these creds the way they are right now, especially when delegating to these dreps. This CIP also makes it efficient to store such credentials.
Again, I am not suggesting we do the changes at the ledger level, as it isn't the goal of this CIP, it is only an off-chain tool spec.

This CIP's goal was never to change the CDDL or ledger spec. It has always been an off-chain spec for byte representation and bech32 encoding for various government-related credentials and identifiers.

Glad to hear, I was worried there for a moment :sweat_smile:

We just realized that this spec may also be helpful at the ledger level.

Any offchain representation that does not affect CDDL has no use to ledger, since only input we ever care about is encoded in CBOR.

it has been long exploited by tx metadata,

Not quite sure what you mean there about metadata.

Instead of having a list of tx ID, and index bytes, it should bring efficiency by just using this CIP action ID, since you mention there will be millions of votes, and each vote will also have an action ID.

Why stop there, transaction_input would benefit from this optimization even more :sweat_smile:
I agree, that it would be more efficient, but that would not be valid CDDL, so we can't really use it on chain.
Currently, I believe, there are only two types that use custom binary representation instead of CBOR, which also means that they cannot be described in CDDL: payment addresses and plutus scripts.

With respect to plutus scripts, I think it is totally fine to have custom serialization.
When it comes to addresses I can't tell what was the reason for using custom format. Looks like it was initially implemented with CBOR, but then replaced with custom format in https://github.com/IntersectMBO/cardano-ledger/pull/1412 Maybe it was motivated by efficiency, maybe by something else, I don't know because it predates everyone on the ledger team.

Unless there is a really really good reason to deviate from CBOR in favor of a custom binary format for some type(s) we are not even going to consider adding more cases to this exception list.

It's not great that the drep prefix will change its meaning.

100% agreed. If this proposal has to exist at the very least it can extend the courtesy to not inflict standard conflicts that cause nothing but confusion for users. A custom bech32 prefix should rather be used for a custom bech32 encrypted content. An already merged convention defines drep1<key> meaning that the <key> value will be a plain Ed25519KeyHash. This proposal breaks it, while it doesn't have to. It can be changed to something like drepx1<val> meaning the <val> will be that "extended hex" value with encoding prefix byte.

While drep bech32 prefix does conflict with merged CIP-105, they are distinguishable by the length of the bech32 drep id. I just wanted that said.

While drep bech32 prefix does conflict with merged CIP-105, they are distinguishable by the length of the bech32 drep id. I just wanted that said.

Ima tell users to make sure they check the length of the ID they are getting so they can know if all apps will accept it.

While drep bech32 prefix does conflict with merged CIP-105, they are distinguishable by the length of the bech32 drep id. I just wanted that said.

Ima tell users to make sure they check the length of the ID they are getting so they can know if all apps will accept it.
Or we can just agree to use custom prefixes for custom values and make things immediately easier for everyone.

I have no problem with your suggestion, only meant that from a programmatic perspective, it can be used to distinguish them. But using unique prefix would make it even clearer, especially from user pov.

i think that CIP129 is ok as it is right now. also already adopted by a bunch of apps. CIP105 was rushed, not CIP129. i pointed out that we have to make this right 1,5 years ago. CIP105 failed to deliver it, but we used it anyways. a lot of tooling has CIP129 now in tegrated, i don't see a reason to change this all over again. imo it would be better to switch over to CIP129 and don't use CIP105 anymore.

imo it would be better to switch over to CIP129 and don't use CIP105 anymore.

I will now just out of making a point say that IMO an opposite should happen. Even tho I don't really care. What now? We can keep having arguments about which thing is better or not and have this never merged. Or we can just stop having hard feelings about standards and agree that if some other proposal got merged first and reserved a use of a certain prefix for a specific case then other proposals that are not merged yet can adapt and make life easier for everyone including themselves , increasing the chances to get globally adopted, but at the very least being backward compatible with the existing state of the things. This proposal can then get merged and get adopted by all the projects that claimed they will be ready to implement it when that happens, and let CIP105 naturally die out over time, if that is what meant to be. Anyone who implements an unmerged proposal should always be ready it might change, that's the whole point and why so many projects are waiting for this to get merged before adopting it.

@vsubhuman @ashisherc @Ryun1 to keep this conversation going. is the only thing that is holding this pr up from being accepted the overlap in the bech prefix?
the gov_action prefix was introduced by this cip-129 draft. so there is no need to change that.
for the others we would have to change them like:
   drep -> drepx
 cc_hot -> cc_hotx / ccx_hot
cc_cold -> cc_coldx / ccx_cold

?

@gitmachtl this PR updates the previous CIP prefixes. Hence once merged, it will avoid confusions.

@ashisherc i don't see any willing from IO side to update there tooling, so most likely this PR will go nowhere anytime soon if we overwrite the prefixes.

I'm working on cardano-wallet, the business logic for Daedalus, and randomly came across this CIP as part of implementation questions.
To clarify: Am I understanding this right that merging this pull request will retroactively change the active CIP-105 standard to no longer define the drep prefix?
I'm asking because this means that the phrase "our wallet is compliant with CIP-105" will mean different things at different points in time, causing confusion for users?

Hello everyone here :)
Apologies for coming late to the party. I just wanted to share a perspective from a pure user experience side (I work as Head of product in Intersect and have facilitated the creation of Govtool so far).
Context
We are seeing good participation in governance so far, considering also we are still in the bootstrapping phase, but there has been confusion on the DRep side about registration and how to successfully campaign. Tools (like also govtool) make it a bit easier, but of course, we need also to allow DReps to socialize their ID to people who will not use tools (arguably the delegators with bigger stakes).
Suggestion
Thinking again purely from a user experience, and so a participation point of view, I think it is critical, especially now that we are at the beginning and we need to increase DReps and delegation, to keep information clean and easy. To me this means aligning on one standard (whichever you all believe to be best) otherwise every DRep would need to share two IDs (some of which visible in some tools and some not) and every delegator would need to be aware of which ID to use where. It becomes difficult to manage for DReps, confusing for delegators, and difficult to handle also for tools.
TDLR
If possible, I would recommend investing a bit more time to align all on a path forward that leads to one shared standard so that we can all support good participation in our Cardano government 🙏🏻

@HeinrichApfelmus @l-br1 - I don't know to what extent it will be possible to satisfy everybody's reservations about the implications of merging this proposal.  There is a lot of commentary already in the thread above suggesting that it's worth the risk... or disqualifying the risk to some degree... but that doesn't mean it would be merged without considerations to the contrary, or that we would simply accept "majority rule".
All I can offer for now is that we will include all feedback up until that time, including the comments you have just made.  There will be 2 other editors involved in that decision who haven't expressed opinions recently, and you yourselves (as would all interested parties) are welcome to attend that meeting.

Hi @rphair, I fully understand it's not easy to make everyone happy, and I appreciate your reply and the invitation to the meeting 🙏🏻
If anyone has a proposal that could allow this new standard to be compatible with the existing one or if we see a safe way (and good reasons) to deprecate the existing one for the new one, that would be great. Of course, I am not aware of all the details related to the benefits of this change so I'll rely on the expertise of this group, if they see the value in it, to see if there is such a path forward 🙂

the implications of merging this proposal.

I'd like to make my feedback more precise then: I don't care about the technical content of either this CIP or the other one, but I have an objection on the matter of process.
Specifically,

merging this pull request

does two things in combination:

Accepting CIP-129, introducing a meaning for human readable strings of the form drep1…
Revoking CIP-105, as the wording of the standard is changed to no longer define a meaning for drep1….

The consequence will be that if I make the claim "our wallet is CIP-105 compliant", this claim is true today, but will become false after item 2 has happened. I will have to at least update my website, which however is unmaintained, so the false claim that was once true will persist.
I don't even have an objection against revoking standards, but I request that this be an explicit action. One possible course of action is to do the following:

Retire CIP-105
Accept CIP-129
Accept a CIP-130 (or some other number) which is equal to the now-retired CIP-105, except with the wording change here.

Anyone who wants to know more about the fact that "our wallet is CIP-105 compliant" will then have a chance of finding out that the wallet is outdated, as the standard that it is compliant has been retired.

@HeinrichApfelmus Regarding retiring 105, this proposal doesn't retire 105, only updates a few parts of it mainly regarding the dRep and CC IDs. Further merging this proposal will not affect existing toolings compatibility right away. Infact checkout the tools readiness and most of the tools support both CIP129 and 105 as backward compatibility. Once this proposal is merged, tools can slowly start removing 105 compatibility at their convenience.
Hence to summarise majority of the tooling rightnow are supporting both 129 and 105, and waiting for this proposal to be merged, to avoid maintaining 105 further and reduce confusions that's are being created.

Let me allow to make this comment: I know that this question is now driven from the Daedalus Update. Daedalus is always a bit slow when it comes to integrate new CIPs and functions that are picked up by other wallet way faster. Having no support for Transaction-Messages/Memos is only one of them.
What i would like to see here is, that cardano-wallet as the underlying component powering Daedalus adobt such a new CIP faster. From what i have heard so far from CIP editors, the CIP129 is on a good path to be merged soon. No real blockers there, also a lot of adoption already.
I konw that the dev works on various components are not that easy or not that highly rated when it comes to distribution dev power to it. Just wanna say that i have the fear if this will not be implemented right from the beginning, it will take months before we see it coming to the public.

Once this proposal is merged, tools can slowly start removing 105 compatibility at their convenience.

Again: Once this proposal is merged, tools that were CIP-105 compliant will no longer be CIP-105 compliant, because their use of the drep prefix will no longer agree with the new wording of the CIP-105 standard. Tools cannot slowly remove compatibility even if they wanted to — it will be revoked by merging this pull request.
As I said, this is an issue with the standards process, not with any particular technical choices.

@HeinrichApfelmus If something is compliant with a CIP and a newer CIP comes along, than the product is still complaint with the original CIP. So thta does not invalidate it imo.
I think what we should do - and i already talked with @ashisherc (cip author) about this - is to simply add a seconf line in CIP005 describing the prefix with two different use cases. The prefix drep can exist in both domains. There is currently no need to define one CIP to rule them all.
So you can still keep your statement to be CIP105 complain for a product.

@ashisherc is about to update it like i described above.

Hi all,
Appreciate the discussion on this.
Context

CIP105 provided definition for Conway credentials, including bech32 prefixes

Prefixes for DRep credentials and CC credentials.

Some tooling/wallets have implemented the CIP105 definitions

CIP105 definitions have seemed to broadly worked

A different approach to Conway credentials was proposed via CIP-129

These definitions provide a nicer representation for these credentials

CIP-129 does suggest altering the CIP-105 definitions of bech32 prefixes

This is an issue as it requires a change to an active CIP

Options
a) We change CIP-105 to not claim the prefixes.
b) We change CIP-129 to not claim to the prefixes.
c) We agree that CIP-105 and CIP-129 to both claim the prefixes.
My opinion
I oppose a) as it would mean tooling which is "CIP-105 compliant" would now be broken.
Changing active CIPs has proven to be a mistake time and time again.
Myself and others have suggested b) a couple of times.
This is of course at the author's discretion, and they have chosen not to take this suggestion, I think that is fine.
Although I still think it is worth considering.
With the current context I think c) is the only possible action.
With the caveat that all CIP129 compliant tools should also recognise CIP-105 prefix definitions and handle them.
c) allows for tooling to migrate between the two standards, without outright breaking CIP105 compliant tools.
This means that things could only break when users are copying CIP-129 IDs to CIP-105 tools.
And this seems to be the consensus reached by @gitmachtl + @ashisherc whilst I was writing this response.
Does anyone object to allowing both CIP105 and CIP129 claim these bech32 prefixes?
(tagging a few discussion contributors @HeinrichApfelmus, @l-br1, @vsubhuman, @rphair, @Crypto2099)

@Ryun1 - from my understanding of the discussion so far (and not as a tool developer) I have no objection to option (c) and believe it represents the best chance of moving forward together as a community over this issue.

@Ryun1 - from my understanding of the discussion so far (though not a tool developer) I have no objection to option (c) [CIP-105 and CIP-129 both claim the prefixes] and believe it represents the best chance of moving forward as a community over this issue.

Same. Not perfect, but seems like a way forward. At the very least it makes the CIP recognize that prior state exists and cannot just be erased from documentation.

@Ryun1 Thanks! This makes a lot of sense.
I don't object to c), but I do want to note has the unfortunate and large downside of bringing confusing to users — "Hey, your drep doesn't work" — "Did you use a CIP-129 or CIP-105 compliant wallet?" — "What's a CIP wallet?"?
The only solution to that is to also retire one of the standards in the long term, e.g.
d) We retire CIP-105
Doesn't have to be now.

As i suggested above, i am also for c).
But i would also go further and add in some information in the CIP-005 documentation for CIP105 entries, that there is now a newer version and that CIP105 might get deprecated in the future. So thats about d) @HeinrichApfelmus suggested.

Thanks @Ryun1 for the summary 🙏🏻
From my side (considering participation in Cardano's governance, DReps and delegators' needs and so needs tools should support) I would still stress that effectively creating an 'alternative' DRep ID will require DReps and delegators to be aware of both (without any real benefit and reason for them) and it will add extra unnecessary friction to an already complex experience at its early stages.
So purely considering the perspective of users of our governance system I see this as a step back.
Option C is definitely a way to unblock this easily (just looking at the CIP itself), but even from the rationale and summary in @Ryun1's comment, it doesn't seem the best option for the broader purpose.

@l-br1 in regards of user experience and that "Dreps" must be aware about an other format. In my oppinion its best to do this now, and not wait and sit it out until we have 1000+ DReps on chain.
We should not artificially delay the depoyment of a better solution. CIP129 brings bech representation for ActionIDs too. Thats very nice.
It also provides the solution to not have to deal with
drep
drep_script
cc_cold
cc_cold_script
cc_hot
cc_hot_script
credentials, but reduces that to only three from the six.
I am a bit biased about this whole topic, because i brought up this issue around 1,5 years ago. But noone reacted and it was passed and so only the direct hashes were implemented from the ledger/node/cli team. When the problem occured again, it was stated that "now its too late".
So, i hope we can move forward with this CIP and to provide a reseaonable upgrade path for the Tools that way.

@rphair all conflicts resolved (Pun intended, perhaps?)

yea, thanks everyone involved!


source and destination have same List attachments, not working

I have a mapper like this:
@Mapper(withIgnoreMissing = IgnoreMissing.ALL, withCollectionStrategy = SETTER_ONLY)
public interface  BaseBeanMapper {
NotificationContent asNotificationContent(EmailMessage emailMessage);
}
Both NotificationContent and EmailMessage have "List attachments", I tried all collectionStategy: GETTER_ONLY, Default, SETTER_ONLY, but always getting error:
Error:(15, 25) java: Failed to generate mapping method for type Email.Attachment to
Email.Attachment to Email.Attachment not supported on util.BaseBeanMapper.asNotificationContent(beans.Email.EmailMessage) !
--> Add a custom mapper or 'withIgnoreFields' on @Mapper or @Maps to fix this ! If you think this a Bug in Selma please report issue here [https://github.com/xebia-france/selma/issues].
Any info would be greatly appreciated.
Thanks,
Joe

Actually it is Lombok and Selma issue, Selma processes it before Lombok generates getter/setter. Anyway go around this?

Sadly, Selma is not able to work in the same source tree with lombok.
You can only separate your code in different modules so the compiler can first process lombok and then compile the mappers with Selma.


[Bug]: Multiple scrollbars visible for connections tab in query pages

Is there an existing issue for this?

[X] I have searched the existing issues

Description
We get to see multiple scrollbars inside the connections tab of the query page.
Steps To Reproduce

Run some query.
Scroll inside the connections tab.

Expected: We should only see 1 scroll bar.
Public Sample App
No response
Environment
Production
Issue video log
https://www.loom.com/share/8ee5729ed523422c97c52c0bfbff3b7a
Version
Cloud

Will be addressed in this issue: https://github.com/appsmithorg/appsmith/issues/29322