text:
Document NixPath trait

https://github.com/carllerche/nix-rust/blob/00c7905a8a85668d0993420e356a56002ab23905/src/lib.rs#L115
I'm trying to bring back mount (#85) and while I can make it work, I'm not 100% sure of what the purpose of NixPath is. Could do with a 1-2 sentence explanation of why and when to use it. Its name is confusing for mount because the filesystem type is passed as a NixPath, though it isn't really a path.

NixPath needs a major rehaul...

It's a weird Into<CString> hybrid-like thing that also happens to use a large part of the stack and checks len against MAXPATHLEN, which isn't really helpful anyway.
The closure with_nix_path usage is super awkward (just look at mount's current commented-out implementation!).
And then there are parts of nix that use &CString!!! These need to be killed and changed to &CStr or AsRef as appropriate. AND it does behind-the-scenes allocations to generate the null-terminated list of strings. That should be its own type instead so the caller can pay that cost up-front! Otherwise you're calling collect::<Vec<_>>() after a fork/clone/etc!

We should basically just use AsRef<CStr> instead. For easy integration with nix, maybe provide a impl From<std::ffi::NulError> for nix::Error when using CString::new. Nix can also provide a new explicit NixPath to use when you actually want the stack allocation and MAXPATHLEN check:

struct NixPath([u8; MAX_PATH]);

impl NixPath {
    fn new<T: AsRef<[u8]>>(t: T) -> Result<Self> { ... }
}

impl AsRef<CStr> for NixPath { ... }

It's a weird Into hybrid-like thing that also happens to use a large part of the stack

The stack usage gave me a lot of confusion with "disappearing" strings! (This was "my fault" for returning the result of as_ptr from the passed in closure, but not quite intuitive...)

We should basically just use AsRef instead.

Using AsRef<CStr> seems limited. Not even CString implements it. Perhaps AsRef<OsStr> would be better. This would also allow passing Path and PathBuf, str, and string. This would require a copy to ensure null termination though... hrm.

The stack usage gave me a lot of confusion with "disappearing" strings! (This was "my fault" for returning the result of as_ptr from the passed in closure, but not quite intuitive...)

Mm, that's the purpose of using the closure. It's not a rare Rust idiom, but shouldn't really be used unless strictly necessary. Lifetimes would normally catch that sort of misuse, but oop pointers!

Using AsRef seems limited. Not even CString implements it. Perhaps AsRef would be better. This would also allow passing Path and PathBuf, str, and string. This would require a copy to ensure null termination though... hrm.

Yeah as soon as I realised that I submitted https://github.com/rust-lang/rust/pull/30616 because that's a huge missing trait impl for libstd. It's silly, it basically means we're stuck with using our own trait instead that's just a clone of AsRef<CStr>. I'd suggest naming it something more descriptive than NixPath this time around, and when the AsRef<CStr> for CString hits upstream we can always just switch over to it.
Alternatively, the trait could look more like so:
trait ToCStr {
    type Target: AsRef<CStr>;
    fn to_cstr(&self) -> Result<Self::Target> { ... }
}

... which would retain the current behaviour of being able to pass OsStrs, Paths, etc. without the closure weirdness. I'm personally not a fan of the hidden conversions though, it feels a bit too magical for a Rust API vs just using AsRef<CStr> on its own (IMO the InvalidPath variant probably shouldn't be part of nix::Error at all, which should only cover errno).

Sorry for the delay! I need remove myself as a blocker (#236 assemble a team of maintainers). @arcnmx Interested? :) If so, please comment there and / or join the IRC channel!
Everything discussed in this thread is pretty much spot on. A lot in nix needs an overhaul. The lib started mostly as a dumping ground for bindings vs. reimplementing them in each lib that needed them. I would like to get a document that covers these kinds of questions and do a pass throughout the lib to unify API styles (see #190).
As @arcnmx mentioned, if a system API accepts NULL to represent not passing a path, then the nix version should take Option<_>. If a path is required, it should take the type directly.
Specifically regarding NixPath and AsRef<CStr>... I agree that NixPath needs to improve and the name is not ideal... AsRef<CStr> seems plausible. Could somebody summarize the pros / cons of it?

Thinking more about it, IMO it may be worth creating a separate type for path arguments vs. string arguments.... to get some type safety. Thoughts?

IMO it may be worth creating a separate type for path arguments vs. string arguments.... to get some type safety

Well, as far as type invariants are concerned, a path is equivalent to a C string. There's not any advantage in making a wrapper type that asserts you meant it to be a path rather than a CStr. libstd has a Path type but that's mostly so that it can provide helper methods for dealing with path components - it doesn't "protect" you from using a &str or &OsStr as a parameter to a method that takes a AsRef<Path>.

Could somebody summarize the pros / cons of it?

The main con is we move the responsibility of converting a string to a null-terminated string from nix to the caller. The nix error type no longer would have an InvalidPath variant, and would simply represent an Errno. It can make code more verbose depending on where your path strings come from. It may force you to add an enum variant to your error types where you could previously springboard off of nix's.
Another minor con is that AsRef<CStr> only landed recently in libstd but we can use our own trait in place of it for now. The main disadvantage is that external libraries need to impl our trait instead of AsRef<CStr> if they want to interop with nix methods without an explicit conversion.
The pro is that it makes for a simpler and more transparent nix design that more closely represents the underlying APIs that it's wrapping. A higher level version that accepts and deals with rust strings can be done as part of #190 discussions.

As a random data point, I've been using the new API in my own project without issue. I prefer having the cost of conversion to CString be up-front and visible and I haven't found it to be a burden for error handling. My project does the usual fork/exec/etc. dance so it's important that these conversions are done in advance in order to avoid allocations (dangerous if the process is multithreaded) or blowing up a small stack after the fork.

If we're dropping the InvalidPath variant, can we just use std::io::Error with from_raw_os_error instead?

We could! I think nix::Errno fits well though, it has a From<Errno> for io::Error impl so that try!(errno) "just works". This way you can inspect the errno if you like as opposed to using error.raw_os_error().unwrap() or whatever, and there's not much friction with functions that return io::Error.
It's kind of tangential to dropping InvalidPath though, since that already could've been expressed through io::Error as well (and is already done so in libstd). I'd almost say io::Error would've made a bit more sense before this change than after.
The question really becomes whether we want to drop the Errno type entirely or not, which is a whole other discussion. Considering the discussions in #190 about higher-level abstractions over nix, it may make more sense to do this there, especially when errno may not be the only way for a method to fail (like in, say, string conversions).

Considering the discussions in #190 about higher-level abstractions over nix, it may make more sense to do this there

Sounds good.

A relevant comment from @mbr on #245
That currently seems a little messy and missing an implementation for `&str`? Interface names are not `Paths` and I don't want to require passing in `CStrings`, because at that point it stops being a Rust-Interface, I think.

The comment I linked makes me think we should have a module that provides an additional NixString impl that increase ergonomics:
impl<'a, T: AsRef<OsStr>> NixString for T { ... }

We'd need a way to report NUL related errors back though, so I'm not sure about this yet.

Thinking a bit more, this complicates the plan to replace NixPath with a NixString that is equivalent to AsRef<CStr>. Two options I can think of:

allow the method on NixString to return a Result
have a parallel module hierarchy that allows using the more Rusty types

at that point it stops being a Rust-Interface, I think.

This is related again to #190: just how low-level is nix, how much behind-the-scenes magic will there be, etc? I'm not sure I consider nix to be a Rusty API so much as just a more ergonomic and type-safe liblibc. Abstractions can then be built on top of it.
These methods simply take a C string, it's their definition. Making it more vague is similar to say mount()'s flags argument taking an i32 instead of MsFlags and calling from_bits(etc) internally, setting aside an error variant for when it fails. It's a question of "do we take a more liberal set of types and allocate extra error variants for when they fail to convert" vs. "do we only take the infallible types and push the burden of conversion to the caller". The reason to do the former is mostly for convenience. I favour the latter as it's more KISS and composable. I'm also just not a fan in general of hidden functionality when it involves allocations.
One could also argue that encouraging people to write higher level abstractions over nix methods for convenience and create a more "rusty" API is advantageous vs providing something almost good enough to be used ad-hoc in rust applications!

AsRef picks up str, String, Path, PathBuf, OsString. We'd need a way to report NUL related errors back though, so I'm not sure about this yet.

allow the method on NixString to return a Result

This is what NixPath currently is, modulo length checks and perhaps the stack allocations would become heap allocations.

have a parallel module hierarchy that allows using the more Rusty types

This would be a layer on top of the current nix, I guess. Could have fancy things like open() returning an Fd type with read/write member methods, etc! I certainly think there's a place for this.

Ok, I want to get down some of my thoughts on this issue.
There are two conflicting desires I'd have for strings and nix:

no allocation required if I want to do null-termination myself. Eg, if I have a String, I can turn it into a CString and use that
passing Rusty string types to system libraries, eg passing a &str or &OsStr or &Path

@arcnmx is prioritizing (1) in #230 which I think is the right choice for zero-cost Rustification of system APIs.
At the same time, I want to be able to just write mount(None, "somedir", "tmpfs", MS_NOSUID, None) without having to create the CString or CStr myself. I think that is a good aim for Rustification, but it is not zero-cost.
One way to make this available in nix would be to have a conveniences* module that has a convenience impl NixString for T where T: AsRef<OsStr>** which do allocate and copy. This would allow uses like (2).
* name can be bikeshedded later
** this may need some indirection through an extension trait to get around coherence and ensure it's opt-in

Wait! @arcnmx, did #230 always have ToCString?

Writing up a couple of ideas that cam up in chat with @arcnmx today. Transcript: https://gist.githubusercontent.com/kamalmarhubi/fa5f1dc7121c99c04117/raw/61a65cd4694edf63bd5318b93159fadb173fea02/%2523nix.log
There's a tension between ergonomics and minimizing overhead and cruft. We came up with two ideas to allow the the convenient and ergonomic impl NixString for &str etc:

return EINVAL if there are interior nuls or if there is no nul terminator, and log at debug level that the cause was some nul error

pros:

we don't clutter up the error type with string a string related case

cons:

we're returning and EINVAL that didn't actually come from the system
the user has to build with env_logger and run with RUST_LOG=nix=debug to find out what went wrong

add an associated error type to the NixString trait. For CStr it can be Errno, but for &str it can be an enum like Error is currently, with a case for invalid nul termination

pros:

user can opt into ergonomic impls which will be handy for prototyping, but can still switch to explicit nul handling

cons:

the error type depends on the concrete string type passed in. This can be made nicer with From impls that change the string error to EINVAL, for example.

I quite like the second idea, which @arcnmx suggested. It feels like a very clean solution to the problem.

I do not like the first idea, mainly do to the first counter argument listed.

I've rebased #230 on to current master and will experiment with the associated type approach.

In #365 we're discussing mkstemp(3), which takes and mutates a (conceptual) &mut CStr. See https://github.com/nix-rust/nix/pull/365#issuecomment-216374309

#444 drops support for Rust < 1.7, which means we can get the AsRef<Cstr> impls that @arcnmx added many moons ago in https://github.com/rust-lang/rust/pull/30616.  I will give it some thought after Rust Belt Rust, and aim to put up an RFC draft in the next few weeks. My recent revisiting of (mount #446) reminded me how horrible NixPath is...
    let res = try!(try!(try!(try!(
        source.with_nix_path(|source| {
            target.with_nix_path(|target| {
                fstype.with_nix_path(|fstype| {
                    data.with_nix_path(|data| {
                        unsafe {
                            libc::mount(source.as_ptr(),
                                       target.as_ptr(),
                                       fstype.as_ptr(),
                                       flags.bits,
                                       data.as_ptr() as *const libc::c_void)
                        }
                    })
                })
            })
})))));

―https://github.com/nix-rust/nix/blob/master/src/mount.rs#L60-L75

authors: arcnmx carllerche fiveop kamalmarhubi

repo: carllerche/nix-rust


text:
🚀 Release  1.3.1

:robot: I have created a release beep boop
1.3.1 (2022-10-13)
🚨 Bug Fixes

removal of unnecesarry files (7057584)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/carlosdevpereira/test-publish-to-cloudflare/releases/tag/v1.3.1 :sunflower:

source: gharchive/pull-request

license: MIT

license_type: permissive

license_source: github-api


text:
Zone file comments

Hi,
First of all THANK YOU!  this saved me a heap of time converting zone files!
I just noticed a small error on conversion though, we have some zone files commented with a leading  "#", checking the bind zone file syntax the following are valid;
/* This is a C-style comment */
// This is a C++-style comment
# This is a shell-style comment

An example of the current output when # commented record is processed is;
resource "aws_route53_record" "#host-domain-com-CNAME" {
   zone_id = "${aws_route53_zone.host-domain-com.zone_id}"
   name = "#host-domain-com."
   type = "CNAME"
   ttl = "300"
   records = ["cnamehost-domain-com."]
}

This results in an Terraform error
Error: aws_route53_record.#host-domain-com-CNAME: #host-domain-com-CNAME: resource name can only contain letters, numbers, dashes, and underscores.
Obviously this is just because of the "#" in the record name and record can/should be skipped/ignored.

Hi @nalberti!
Glad you found it useful, and sorry for the issues. I've had a look, and it seems that RFC 1035 only allows ; for comments, and this is what the parser I use is following. While the BIND server is a bit more liberal, and allows more comment styles outside that spec.
I couldn't find any grammar in the BIND documentation exactly where those comment styles are allowed, though. They aren't even mentioned in the zone file section. Did you find something about this? There's potential for making parsing a bit harder if you can have something like foo IN /* mid-line comment */ A 127.0.0.1 # More comments

After some testing, it appears BIND does not accept /* ... */-style comments in zone files (but in other configuration files), so at least that complication is avoided:
/*test.example.com. IN A 127.0.0.1*/ leads to dns_rdata_fromtext: /var/cache/bind/test.zone:5: near '127.0.0.1*/': bad dotted quad

I see what you mean.. I just read though the BIND Admin guide to see if there was anything specific to zone files however it only appears to detail comments as they generally relate to configuration files.
My interpretation is that includes zone files however your test indicate otherwise.
The only guess I have is the examples show a space post/pre "*", I wonder if that makes the difference.
Here is a relevant excerpt;
http://web.mit.edu/darwin/src/modules/bind/bind/doc/html/comments.html

I had a short discussion about this, and it turns out BIND might actually be violating DNS spec here by filtering out these, and the parser is doing the "right" thing by not doing so. # is a valid part of a DNS name, so #foo.example.com is a valid record... Surprised me, but so it is, apparently.
So, in the general case it would be correct to do nothing and expect the user to filter the files. However, since BIND does this, I believe this utility could do the filtering as well before passing it off to the (technically correct) parser.
I'll try to implement this tomorrow!

Hahah, wow, you are indeed correct!
I double checked and BIND is indeed serving the record #host.ourdomain.com in our public DNS!
So I agree with your suggestion that its just the Terraform resource name not supporting what is a valid host name character that is the issue.
Honestly, I doubt this issue would ever come up again, just based on the rarity of having a "#" as part of a host name and/or the widespread use of hash commented zone files.

@nalberti Would you mind giving this version a try and see if it works for you? https://6-61497387-gh.circle-artifacts.com/0/bzfttr53rdutil
Would also be fantastic if you could validate that it also does not result in any difference on the old files - I had to do a fair amount of restructuring of the code. I've done quite a bit of validation, but I don't have access to any of the large or "long-time maintained" zones that I initially developed this for.

Appears to work fine, I tested on  3 different zone files of my own and 2 random/sample ones found online.
The output was identical, verified by file size and diff.
Terraform plan also ran against the output fine.
Anything else you would specifically like me to test or further information ?

Great, thanks a lot! That should be enough validation, I'll go ahead and merge and create a new release :)

source: gharchive/issue

authors: carlpett nalberti


text:
batch_norm didn't really distinguish training/testing

The current implementation of batch_norm seems problematic to me that it always assumes training mode.

Why do you think so? I think inference mode is defined like this and variable is shared with this

my mistake, close

license: mit

license_source: bigquery


text:
Package consumers should have the option to install the latest available version of a package without it being auto-updated

Describe the problem/challenge you have
When installing a package, the consumers can either provide a specific version to install OR they can provide some constraints which will keep the package updated to the latest version satisfied by the provided constraints.
There is another use case where a consumer might want to install the latest available version of the package however does NOT want it to update when a new version is available. So, for example, if there are three versions of a package available (v1.0, v2.0, and v3.0), they would like to install the latest that is v3.0 but NOT update it automatically when a new version (v4.0) is available.
Describe the solution you'd like
[A clear and concise description of what you want to happen. If applicable a visual representation of the UX.]
Anything else you would like to add:
[Additional information that will assist in solving the issue.]

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

This one feels weird, why not just provide the constraint? I guess a lot of the context of this one might be lost, so I am going to leave it open for archive sake, but I don't see this being worked on for the foreseeable future

authors: neil-hickey vibhas

repo: carvel-dev/kapp-controller


text:
modified Backend

Signed-off-by: 顾晓阳  guxiaoyang@bupt.edu.cn
Fixes : [#96 ]
Description :

Add PolicyList for policy get/post.

Modified for edit/add/delete.

Screenshot of changes :

Please ensure Checkmark the following :

[x] - Tested Localy
[x] - Checked in IE11 and Firefox
[ ] - Checked in mobile
[x] - Backend work
[ ] - Frontend work
[x] - Bug Fixes
[x] - Enhancements

@BetaCat0

repo: casbin/casbin-dashboard


text:
[crowdin] remove useless words in Crowdin v2 project

Compare our Crowdin v1 project: https://crowdin.com/project/casbin

with v2 project: https://crowdin.com/project/casbin-website

Actually v2 docs and v1 markdown docs are exactly the same, but v2 crowdin has 10,000+ words more than v1's. This already casues our v2 site suspended due to exceeding the word limit set by Crowdin.

Actually I found v2 has another i18n folder to translate, is it useless? If yes, we should delete it to reduce word count.
v1 folders: https://crowdin.com/project/casbin/zh-CN

v2 folders: https://crowdin.com/project/casbin-website/zh-CN

@Selflocking

Fixed by: https://github.com/casbin/casbin-website-v2/pull/30


text:
Rune tracking issue

[x] Publish rune to ordinals.com
[x] Show rune on pages of inscribed ordinals
[x] Link to ordinal from rune
[ ] Write a chapter of the book on runes
[ ] Finalize hashing algorithm
[ ] Finalize metadata format #624
[ ] Include rune hash in transaction to establish "created before" date
[ ] Show current address and utxo of ordinals
[ ] Inscribe rune on range of ordinals
[ ] Inscribe rune on multiple ranges of ordinals
[ ] Inscribe rune on range of ordinals with step
[ ] limit rune name to a-z
[ ] Include media in rune that represents rune itself
[ ] View all published runes at /rune or /runes
[ ] Don't allow publishing runes with unknown fields
[ ] Formalize or get rid of json representation
[ ] Don't allow ordinal to be represented as anything but integer in rune
[ ] Write a chapter of the book on ordinal and rune privacy
[ ] Define consistent terminology for runes, merkle scripts, links, tokens, slots, assets, inscribed ordinals
[ ] Include block hash in rune to establish "created after" date
[ ] Include one or more pieces of media in rune that are assigned to inscrbied ordinals
[ ] Sign rune with well-known public key
[ ] Sign rune with pubkey of an ordinal and relationship (issuer "i made this", verifier "these details are correct", fan "i like this")
[ ] When a rune is included in chain, have notion of issuing ordinal, which is an ordinal that participated in that transaction
[ ] Consider numbering runes sequentially
[ ] Consider representing runes with younger futhark
[ ] Use /BLOCK/TRANSACTION/INPUT for slot notation, /BLOCK/TRANSACTION if first input in transaction, /BLOCK if in coinbase input. SLOT.N is Nth ordinal in rune
[ ] Call them "paths" instead of slots
[ ] Use /BLOCK/TRANSACTION/INPUT/LEAF so that a single taproot tree can commit to arbitrary many runes
[ ] Resolve paths from root: ordinals.com/BLOCK/TRANSACTION/INPUT/LEAF
[ ] Resolve paths to individual ordinals within rune with: ordinals.com/BLOCK/TRANSACTION/INPUT/LEAF.OFFSET
[ ] Some way of giving runes nice names. Maybe first rune included in block with a given name.
[ ] Define a text encoding for runes
[ ] Accept runes by mail
[ ] Explain rune scarcity
[ ] consider using u64 or u128 for rune name and encoding in same way as ordinal name

This is all too speculative for an issue.

repo: casey/ord


text:
COOPR-675 provisioner refactor master

this is the first part of https://issues.cask.co/browse/COOPR-675
this PR moves the provisioner master into coopr-provisioner/lib (eliminating the master directory), and updates a few related paths.
This PR will break standalone on develop.  https://github.com/caskdata/coopr/pull/910 and a submodule ref update will fix it.

Update the Rakefile to point to the new specs.

repo: caskdata/coopr-provisioner


text:
Request - alternote

Alternote is an alternate client for Evernote. http://alternoteapp.com/

Added in https://github.com/caskroom/homebrew-cask/pull/13440.

Fantastic!

authors: Ngrd rstacruz

repo: caskroom/homebrew-cask


text:
Add zap to tunnelblick.rb

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Thank you for the contribution. It needed some fixes, so they were made in efe3225dc7d3f6e2042f1d298bbf0e830f84db95. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.

@adidalal Thank you for all your assistance.

authors: adidalal chuanxd


text:
Add AWA v1.4.2

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

Mistakenly rebased


text:
Update station to 1.7.0

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Sorry but PR #44423 was posted first.

Closing as duplicate. Thank you anyway for the submission, @naotone.

authors: CryoRenegade naotone vitorgalvao


text:
🛑 6xTask is down

In e9cb17c, 6xTask (https://6xtask.co.uk) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 6xTask is back up in fc550e0.


text:
Using Mainnet data joining node not  progressing historical syncing while in keepup

Issue: Using mainnet data when one node is joined to the network it is keepingup but unable to progress on historical sync. We see a checksum warning as well( see below) but that is expected
Name: ajith-mainnet-clone
Network: 5 + 2
Branch: dev
Chain: public
Commit: 17ef14ddd9ac426ffed45b5ace8e7e700ebeeb1c
Config Override: None
Joining Node Testing Mainnet Snapshot ( 1034499 )
Tests:
1 x sync_to_genesis joining
Results: Transitioned to KeepUp but not progressing with historical sync
Observations:

**joining node transitioned to KeepUp and in-sync with tip

status - block_sync ( not progressed since 1+hrs)**

"acquisition_state": "have global state(1034492) for: block hash 01c9..3011"
seeing events as 'checksum uncheckable execution results'
{"timestamp":"2023-01-18T04:10:21.664255Z","level":"INFO","fields":{"message":"BlockSynchronizer: need next for block hash 95bd..31b9: execution results for block hash 95bd..31b9 or chunk #0 (checksum uncheckable execution results)"},"target":"casper_node::components::block_synchronizer"}
"block_sync": {
"historical": {
"block_hash": "95bda7601307f5d1d954bae9938f6ee70121bd2ef90077d9daddb33c2e4731b9",
"block_height": 824808,
"acquisition_state": "have global state(824808) for: block hash 95bd..31b9"
},
"forward": null
}
Dumps: http://genesis.casperlabs.io/ajith-mainnet-clone/casper-node-dumps/ajith-mainnet-clone/18012023_0405/dump_download_list.txt

@thamps-casp for visibility

Keeping the issue as Open since the fix should be confirmed by @thamps-casp

This was closed by a fix here https://github.com/casper-network/casper-node/pull/3665

authors: cspramit rafal-ch

repo: casper-network/casper-node


text:
GH-1972: Fix transfer bench

Closes #1972
This PR fixes the transfer benchmark's Mint(0) error by increasing the new account's minimum balance.

bors r+


text:
Add to onboarding reproduction logs

Mac OS Sonoma v14.4.1
2.0GHz quad‑core 10th‑generation Intel Core i5, Turbo Boost up to 3.8GHz, with 6MB shared L3 cache 16GB of 3733MHz LPDDR4X onboard memory
Successfully run and produced result

Please continue along the onboarding path until you reach the end of the exercises, and then we'll take a look all at once.

Seeing no follow-up, closing.

authors: ShirleyWQQ lintool

repo: castorini/anserini


text:
Telemetry added to project

Adding  Opentelemetry   to the project to better monitor the productivity of the service and to detect potential errors more quickly and ...

@HRNasr what do you mean by monitoring services? Casvisor is about assets (machines and DB), not services. Are you talking about CasWAF? https://github.com/casbin/caswaf

authors: HRNasr hsluoyz

repo: casvisor/casvisor


text:
how to use transaction?

can not find transaction function?

http://medoo.in/api/pdo

authors: catfan ideamean

repo: catfan/Medoo


text:
fix(invidious): password prompt

🔧 What does this fix? 🔧
as said in the title

🗒 Checklist 🗒

[X] I have read and followed Catppuccin's contributing guidelines.
[X] I have updated the version appropriately in the ==UserStyle== header of the catppuccin.user.css file.

Didn't update the version, but I'm planning on a few more fixes in a second anyway.

oh yeah i forgot to update the version

oh yeah i forgot to update the version

That's what the checkboxes are for! Supposed to make you think before you check them off.

That's what the checkboxes are for! Supposed to make you think before you check them off.

yeah i could've just reread the guidelines before making the pr

Or you could have read the wrods on the pull request template you filled out. EIther way, I missed it too.

yeah

@uncenter btw can i dm you on discord to ask some off-topic questions?

yeah

This is noise. A thumbs up will do please.

btw can i dm you on discord to ask some off-topic questions?

Uhh sure.

@uncenter hey uncenter im sorry for what happened on the dms, i was just asking a simple question about nix

repo: catppuccin/userstyles


text:
fix(codeberg): secondary menu, inline code

🔧 What does this fix? 🔧
Items in secondary menu colors are reversed when they are hovered but not for active(selected) one.
Inline code blocks use accent colors and it makes them hard to read.
Here are screenshots(no secondary menu one because I couldn't figure out how to screenshot while hovering items)
before

after

🗒 Checklist 🗒

[x] I have read and followed Catppuccin's contributing guidelines.
[x] I have updated the version appropriately in the ==UserStyle== header of the catppuccin.user.css file.

Thank you!


text:
Fix activate and enhancement

fix automatic activate
add NSLayoutHorizontalAnchor
add NSLayoutVerticalAnchor
extend NSLayoutConstraint

Codecov Report

Merging #6 into master will increase coverage by 0.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master       #6      +/-   ##
==========================================
+ Coverage   99.53%   99.63%   +0.10%
==========================================
  Files          14       17       +3
  Lines         213      271      +58
==========================================
+ Hits          212      270      +58
  Misses          1        1

Impacted Files
Coverage Δ

Mag/Extension/NSLayoutConstraint+Activation.swift
100.00% <100.00%> (ø)

Mag/Extension/NSLayoutConstraint+Properties.swift
94.11% <100.00%> (+0.78%)
:arrow_up:

Mag/Foundation/LayoutConstraint.swift
100.00% <100.00%> (ø)

Mag/NSLayoutDimension+Anchor.swift
100.00% <100.00%> (ø)

Mag/NSLayoutHorizontalAnchor.swift
100.00% <100.00%> (ø)

Mag/NSLayoutVerticalAnchor.swift
100.00% <100.00%> (ø)

Mag/NSLayoutXAxisAnchor+Anchor.swift
100.00% <100.00%> (ø)

Mag/NSLayoutYAxisAnchor+Anchor.swift
100.00% <100.00%> (ø)

Mag/Operator/LayoutAnchorProtocol.swift
100.00% <100.00%> (ø)

Mag/Operator/LayoutDimensionAnchorProtocol.swift
100.00% <100.00%> (ø)

... and 4 more

Continue to review full report at Codecov.

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

repo: cats-oss/Mag