Unions with unsized variants

I believe it would be technically feasible (easy, even) to have unions with at most one unsized variant.
Unsizing should be safe:

T -> dyn U: The vtable contains 2 values relevant for the unsized union:

The alignment: This is stored directly in the vtable of T, accessing it does not access the data pointer
The size: Same.

Note that drop_in_place is not relevant because unions do not drop their contents.

[T; N] -> [T]: The metadata consists of the array length which is statically known and does not require accessing the variant.

@eddyb: In the last paragraph here you wrote that there is a problem with unsized unions but I haven't been able to figure it out. Maybe you were talking about unions with more than one unsized variant?

The problem is that the meta-data in the fat pointer won't always be valid, i.e. what should this do?
union Foo<T: ?Sized> {
    value: T,
    uninit: (),
}

let foo = Foo::<i32> { uninit: () };
let foo_ref = &foo as &Foo<dyn Any>;

Also, if you ban accessing the data, it makes it harder to implement something like Custom DSTs. Custom DSTs are important because they would allow CStr to be a thin pointer. (Is unsized unions that important? I don't know, maybe, maybe not)

The problem is that the meta-data in the fat pointer won't always be valid

Yes, and? Afaik, the only parts of the metadata that MUST be valid are size and alignment so that the layout can be computed at runtime. The other parts (drop_in_place and trait methods) cannot be accessed without first accessing the unsized field. Accessing the wrong field is already undefined behavior so that the metadata being invalid does not add any additional unsafety.

Custom DSTs are important because they would allow CStr to be a thin pointer.

CStr is not a union.

I'm not clear on why CStr can't already be a thin pointer.

Any map T -> dyn U for T: !Sized sounds quite extreme for Rust.  It'd require Box, et al. magically copy the vtable somewhere, not sure that's zero cost, and really not sure what all that breaks.
I think previous discussions indicate that truly unsized types should panic whenever accessing their size or alignment, so align_of_val and size_of_val should never access their data pointer.
If I understood, Rust could add some TrueCStr (name?) which yields thin pointers, and maybe even makes align_of_val work, but for which size_of_val panics.  It'd still have a method like strlen and a conversion into slices.

but for which size_of_val panics

that would make Box<CStr> crash

Please let's stop this academic discussion around CStr. CStr will never be changed simply because it would

Completely change the performance characteristics of a core type that is relied upon by lots of production code.
Break all code that relies on transmuting CStr to [u8] of which I assume there is much.

People who actually want a thin pointer to null terminated strings have written such a thing themselves years ago and have no need for a thin CStr.

Feel free to talk about new forms of metadata in general.

I don't know how to even implement this. Imagine
union Example {
  a: str,
  b: String,
}

Now, given &Example (which I suppose is a wide pointer), how do you determine the size?
Note that not even enums can have unsized fields currently, and that seems like a strictly simpler problem since for enums we know which variant they are in. So I think we should specify, implement, and gather experience with unsized enums before venturing into the lang of unsized unions.

I don't know how to even implement this. Imagine
union Example {
  a: str,
  b: String,
}

Now, given &Example (which I suppose is a wide pointer), how do you determine the size?

How do you construct &Example? Presumably with transmute? In this case you would either transmute it from &str or from [&String, 0]. So the size would be max(metadata, sizeof(String)). Or more generally for [T] fields:
max(metadata * sizeof(T), sizeof(union without the unsized field))

Automatic unsizing of [T; N] fields would of course set the metadata to the correct value just unsizing &[T; N] would.

Note that not even enums can have unsized fields currently, and that seems like a strictly simpler problem since for enums we know which variant they are in.

I think enums are significantly more complicated in this case. The &Example above can be constructed via transmute. If it were an enum, this would not be possible.

How do you construct &Example?

That doesn't matter for my question. No matter how it is constructed, you have to be able compile code like
fn example1(e: &Example) -> usize { mem::size_of_val(e) }

fn example2(e: Box<&Example>) { drop(e) }

in a uniform way, without know how they got created.

max(metadata * sizeof(T), sizeof(union without the unsized field))

So you are suggesting that the metadata is 0 when the String variant was used to create this enum? Leaving aside that it is completely unclear how to do the unsizing coercion, what do you propose to do if the unsized field is of type dyn Trait? (Note that the vtable metadata field is currently marked nonnull.)

So you are suggesting that the metadata is 0 when the String variant was used to create this enum?

We're talking about unions and not enums. The variant does not matter for unsizing and the compiler does not have to know which variant was last written to.

Leaving aside that it is completely unclear how to do the unsizing coercion

Which part is unclear? Given
union X<T> {
	t: ManuallyDrop<T>,
	v: ManuallyDrop<String>,
}

X<[u8; 22]> unsizes to X<[u8]> with metadata 22.

what do you propose to do if the unsized field is of type dyn Trait? (Note that the vtable metadata field is currently marked nonnull.)

X<u8> unsizes to X<dyn Clone> with the metadata of u8 as Clone.
Accessing the wrong field is simply undefined behavior. E.g.
let x: X<u8> = X { v: ManuallyDrop::new(String::new()) };
let x: &X<dyn Clone> = &x;
unsafe {
	x.t.clone(); // UB
}

(The current rules for sized fields are a bit more relaxed but for unsized fields we can simply make up the new rule that accessing an "inactive" unsized field is unconditionally UB.)

btw, since you mentioned that earlier -- note that unsizing-by-transmute is incorrect since the layout of wide pointers is not specified.

X<[u8; 22]> unsizes to X<[u8]> with metadata 22.

Oh, I see. That makes sense. Basically where struct with unsized field adds up all the static field sizes with the one of the unsized field, union takes a max instead. Unsizing will always be able to determine that size without looking at the data stored in the union because pre-unsizing, it is all present in the type. Initializing a X<[u8; 22]> requires specifying the 22 even if we initialize it in the String field -- this is the bit that I missed before.
This also works for dyn Trait.
When nesting union and struct, this can lead to more complicated code for size_of_val (a sequence of additions and max), but it is still possible to implement this in time linear to the depth of the type (so far it's constant, though). Maybe there is a more clever compliation strategy, but that's not something I am fundamentally worried about.

(The current rules for sized fields are a bit more relaxed but for unsized fields we can simply make up the new rule that accessing an "inactive" unsized field is unconditionally UB.)

There is no such thing as an "active" or "inactive" union field, and I think adding that notion would be a mistake. (It would also be quite complicated.) It also seems unnecessary -- your code is equivalent to reading x.t from the original sized x, i.e., it can still be explained by "union field accesses are transmutes".

The one issue that remains is the same as what I mentioned in https://github.com/rust-lang/rust/issues/80158: this proposal relies on determining the size of Box<T: !Sized> without accessing the pointee, which is in conflict with very general proposals for custom DST. That conflict could be resolvable in principle, but will lead to a lot of friction nevertheless.

rc::Weak already calls align_of_val_raw on invalid pointers.

rc::Weak already calls align_of_val_raw on invalid pointers.

The code is careful to spell out that it is valid only when the "unsized tail" of T is a slices or a trait object. AFAIK the public API of Rc makes it impossible to create other Rc<T> for unsized T, even if the respective unsizing coercions were added. Do you see a loophole in that approach?

The code I was thinking of is
https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=62b9754a432976a2646cf30812e60913
If I understand you correctly, you're saying that Weak<T> can never be safely converted to Weak<U> where U is not sized but neither a slice or a trait.
The only other unsized types I'm aware of are extern types and I'm not aware of any way to coerce any type to an extern type. Therefore this statement would be trivially true current language and also hold for unions.
But even if there were special logic (maybe some marker trait?) that allowed Weak to coerce to slices or traits but not to other unsized types, could the same logic not also be applied to unions without extending the language?

That code is obviously wrong since you are using as_ptr on a dangling Weak.
But I didn't know/remember that Weak supports arbitrary unsizing coercions, I thought there'd just be a few select constructors. Cc @CAD97 who added unsized support for Weak (IIRC).

That code is obviously wrong since you are using as_ptr on a dangling Weak.

I should not have added that unsound unsafe block because now it's not clear if you meant that calling the safe function as_prt is wrong in itself or that dereferencing that pointer is wrong.
The following gist without that block is sufficient to demonstrate the issue: https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=be21e33e1d74345e13d90947147617c0

Cc @CAD97 who added unsized support for Weak (IIRC).

Yep, that me. Though to be clear, this was

rc::Weak already calls align_of_val_raw on invalid pointers.

This is... actually true, as you've demonstrated. I guess I need to reword the safety docs around that, and may be to blame for limitations on unsized values in the future 😅
The important part and what I argued at stabilization has to do with validity (as in validity invariant) of the pointer metadata. Even in the unsize coercion of a dangling Weak case, the fat pointer metadata is constructed by normal means.
This is the case even without my stabilization, though:
let rc: Rc<[u8; 32]> = Rc::new(Default::default());
let rc: Rc<[u8]> = rc;
let weak: Weak<[u8]> = Rc::downgrade(&rc);
drop(rc);
drop(weak);

Here we drop a Weak<[u8]> that, while not dangling, is pointing to dropped data. As such, even without being able to construct a truly dangling unsized Weak, it would be incorrect for it to read the contained data while drop/deallocating.

Here we drop a Weak<[u8]> that, while not dangling, is pointing to dropped data.

Great example. Of course, RcBox could in theory store the size and alignment of its data proactively which would make the metadata calls unnecessary. But the again so could Box.

The following gist without that block is sufficient to demonstrate the issue

Ah, because as_ptr internally calls align_of_val_raw? I see.

Here we drop a Weak<[u8]> that, while not dangling, is pointing to dropped data. As such, even without being able to construct a truly dangling unsized Weak, it would be incorrect for it to read the contained data while drop/deallocating.

There is a potential fix here by requiring that for custom DSTs, determining the size must be possible even after the drop glue ran (but before the underlying memory got deallocated). However, that still sounds quite awful and would seriously restrict which custom DSTs are possible.

Of course, RcBox could in theory store the size and alignment of its data proactively which would make the metadata calls unnecessary. But then again so could Box.

That is another interesting idea... custom DSTs could be required to provide a function that extracts all the data now such that, later, this data plus the ptr metadata is enough to reconstruct size and alignment. This extra data would be () but currently existing DST (since ptr metadata is enough) but thin trait objects you put size+alignment into that data, and RcBox/ArcBox could store that extra data.
However... Box isn't actually dropping its content before determining size+alignment, so there's no reason here why Box would have to do this. So something is still wrong here.
Wouldn't this mean ManuallyDrop::take becomes unsound, since it leaves behind a "moved-out-of" unsized thing of which the size still needs to be determinable?

To be a bit more concrete, the case I am thinking about is something like
union X<T> {
	t: ManuallyDrop<T>,
	v: ManuallyDrop<String>,
}
type Problem = X<ThinDst>;

ThinDst would do whatever it takes to become a custom DST, so for X<ThinDst> that support needs to be "lifted" to a union type -- which requires accessing x.t, since that's what ThinDst's custom DST support will require.
IOW, unions are not "structural" for custom DST support, whereas structs are.
The discussion above, as I understand it, is about figuring out to what extend ThinDst is already broken given what is currently stable.

The discussion above, as I understand it, is about figuring out to what extend ThinDst is already broken given what is currently stable.

Yes.

There is a potential fix here by requiring that for custom DSTs, determining the size must be possible even after the drop glue ran (but before the underlying memory got deallocated). However, that still sounds quite awful and would seriously restrict which custom DSTs are possible.

I do not think that is possible. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f6532229a7706836246360fb1af18db3
Code like ZeroOnDrop already exists in the wild. If Display were replaced by a ThinDst, any size information it might want to access would already have been zeroed out at the end of f.

That is another interesting idea... custom DSTs could be required to provide a function that extracts all the data now such that, later, this data plus the ptr metadata is enough to reconstruct size and alignment. This extra data would be () for currently existing DST (since ptr metadata is enough) but thin trait objects you put size+alignment into that data (or just the vtable ptr), and RcBox/ArcBox could store that extra data.

I think there are two ideas here.

dyn Dst pointers store the extra data side-by-side with the pointer. This means that size+alignment can be determined without dereferencing the data pointer. Basically how it works today. But this would probably make thin DSTs impossible and dyn Dst pointers might be very large for some DSTs: data+vtable+size+alignment.
It's up to the container to store size+alignment if it needs to so that it can later be deallocated. The problem with this is that RcBox<T> is always constructed with a sized <T>. To accommodate T unsizing to a custom DST, it would have to reserve an additional 16 bytes in its allocation to be able to store the size+alignment information. If it's not possible to determine at compile time if a type T might unsize to a custom DST, this would add a 16 byte overhead to all RcBoxs.

However... Box isn't actually dropping its content before determining size+alignment, so there's no reason here why Box would have to do this. So something is still wrong here.

By that comment I meant that, if we are willing to pay a blanked 16 byte overhead for all RcBox allocations only to support custom DSTs, then why not do the same with Box to support Box<Union<dyn Dst>>. Box then stores this additional data in its constructor.

Wouldn't this mean ManuallyDrop::take becomes unsound, since it leaves behind a "moved-out-of" unsized thing of which the size still needs to be determinable?

If size+alignment are always calculated by contained constructors which work only with sized types by design, then there is no problem because the vtable is not needed for size calculations.
If size+alignment calculations use the "access after drop/before deallocate" idea you suggested, then ManuallyDrop::take should be fine because it leaves the memory unchanged as I understand it. But the ZeroOnDrop example breaks this either way.

@mahkoh

Code like ZeroOnDrop already exists in the wild. If Display were replaced by a ThinDst, any size information it might want to access would already have been zeroed out at the end of f.

Note: that code as written is unsound because zeroing references/other nonnull pointers is undefined behavior. The fix is to use MaybeUninit, which conveniently doesn't allow unsized types. So that doesn't apply to this discussion.

By that comment I meant that, if we are willing to pay a blanked 16 byte overhead for all RcBox allocations only to support custom DSTs, then why not do the same with Box to support Box<Union>. Box then stores this additional data in its constructor.

Because the Box isn't dropping dyn Dst, it's dropping Union. So it would be on the author of Union to correctly drop dyn Dst.

Note: that code as written is unsound because zeroing references/other nonnull pointers is undefined behavior.

I disagree. Invalidating the state of ManuallyDrop is a supported operation as long as the ManuallyDrop is not accessed afterwards. See ManuallyDrop::drop. Overwriting it is no different since it's not accessed afterwards.

Because the Box isn't dropping dyn Dst, it's dropping Union. So it would be on the author of Union to correctly drop dyn Dst.

It's not about dropping the contents. It's about calculating the size and alignment of the contents.

I disagree. Invalidating the state of ManuallyDrop is a supported operation as long as the ManuallyDrop is not accessed afterwards. See ManuallyDrop::drop. Overwriting it is no different since it's not accessed afterwards.

From the ManuallyDrop docs

ManuallyDrop is subject to the same layout optimizations as T. As a consequence, it has no effect on the assumptions that the compiler makes about its contents.

Also see: https://github.com/rust-lang/unsafe-code-guidelines/issues/245

It's not about dropping the contents. It's about calculating the size and alignment of the contents.

Right, I misunderstood

Is there some good reason for T -> dyn Trait conversions with T: !Sized?

I think there are two ideas here.
..

It's clear both 1 and 2 are non-zero cost for almost all use cases, for what amounts to an extraordinarily niche feature.
Instead metadata should be specified explicitly by pointer types, so either make traits specify their metadata perhaps via trait Foo : Pointee<Meta = MyMeta> {} using #2984 syntax, or else specify in the dyn type so dyn<MyMeta> Trait or dyn Trait+Pointee<Meta = MyMeta> again using #2984 syntax.
In this, one could not ever convert a &dyn<MyMeta> Trait to a &dyn Trait, but perhaps the reverse makes sense sometimes.
As an aside, if one wants more complex metadata then really types like struct Foo([X],[Y]); look much more useful than dyn whatever, meaning &Foo requires one data pointer and two lengths.

It's unsound to zero &T, so it's unsound to zero ManuallyDrop<&T>
Also see: rust-lang/unsafe-code-guidelines#245

Yes it looks like I was wrong. I'll see if I can come up with another example.

By that comment I meant that, if we are willing to pay a blanked 16 byte overhead for all RcBox allocations only to support custom DSTs, then why not do the same with Box to support Box<Union>. Box then stores this additional data in its constructor.

I understand. What I am trying to figure out is which protocol Box would be breaking if it didn't do that. Clearly, a Box that doesn't do this is wrong under Custom-DST + Unsized-Unions. But which safety condition is being violated where?

But which safety condition is being violated where?

That particular statement was not intended to show that there is already a problem with DSTs. (I think that's what you mean by your question which I didn't understand the first time.)

Noting this here before I forget: even without my additional as_ptr/into_raw/from_raw support for Weak<T: ?Sized>, it was already possible to create and drop the last dangling Weak because of unsize coercion:
pub fn main() {
    let weak: Weak<[u8]> = Weak::<[u8; 32]>::new();
    drop(weak); // <-- HERE
}

I think this means that my stabilization didn't add any new requirements to the impl, as they already existed in Weak's drop implementation.

See https://github.com/rust-lang/rust/pull/80407 for follow-up on the dangling unsized Weak issue. With cleverer implementations for our refcounted pointers, they don't require align_of_val_raw at all, so shouldn't be used as rationalization for "it's already possible." See the linked issue for more context and/or further discussion.

That particular statement was not intended to show that there is already a problem with DSTs. (I think that's what you mean by your question which I didn't understand the first time.)

Right, but in a world with your unsized unions and custom thin DST, Box is unsound. So where's the bug, where's the unsoundness coming from, which condition is being violated where?

I'm sorry but it looks like I still don't understand your question. Are you asking where the unsoundness with Box+thin Dst+unsized unions is? You've already spelled it out in this issue. Are you asking where an existing unsoundness with Box+thin Dst is? Like I said, this particular sentence had nothing to with showing that there is existing unsoundness. That sentence was about showing a way in which Box+thin Dst+unsized unions could be made sound.

Are you asking where the unsoundness with Box+thin Dst+unsized unions is?

Yes.

You've already spelled it out in this issue.

I've spelled out what goes wrong, operationally. But I'd like to understand better what happens. Since something goes wrong, clearly a proof of soundness for this system will fail. What I haven't understood yet is where it will fail.
It's one thing to say "having Box store size and alignment up-front fixes this", but that still doesn't say which contract would be violated by not doing so.
So here's my rambling thoughts on this, typing them out pretty much as they come to my mind:
Box only calls size_of_val on live values. I can't see any way that Box is violating the preconditions of anything here.
Thin DST themselves are also fine, I think.
So the real culprit, then, are unsized unions.
Unsized unions essentially mean we have to remove size_of_val and align_of_val from the language -- they become unusable. Literally the only thing Box is doing wrong here is calling these functions. So really the unsoundness is in having size_of_val + thin DST + unsized unions.
So if we were to add unsized unions, then we'd have to accept that size_of_val will not be callable in situations where there might be a thin DST. Notwithstanding the align_of_val_raw issue in Rc that you uncovered, this seems like a big leap.

You make a compelling point.
We want

Have unsized unions at least for those metadata that can determine their layout without accessing the data pointer.
Not make implementing thin DSTs harder.
Not have size_of_val(t) panic just because t contains a union with a thin DST field.
Not add any new type bounds that mean "this is a DST whose layout can be determined without accessing the data pointer."

What about stopping the problem at Unsize?
/// - `[T; N]` is `Unsize<[T]>`
/// - `T` is `Unsize<dyn Trait>` when `T: Trait`
/// - `Foo<..., T, ...>` is `Unsize<Foo<..., U, ...>>` if:
///   - `T: Unsize<U>`
///   - Foo is a struct
///   - Only the last field of `Foo` has a type involving `T`
///   - `T` is not part of the type of any other fields
///   - `Bar<T>: Unsize<Bar<U>>`, if the last field of `Foo` has type `Bar<T>`

All implementations of Unsize are provided by the compiler and, of course, there are currently no implementations specified for unions. How about having the following rules for unions:

T: Unsize<U>
Foo is a union
At most one variant of Foo has a type involving T
T is not part of the type of any other variant
Bar<T>: Unsize<Bar<U>>, if the variant of Foo involving T has type Bar<T>
Determining the size of &U does not require accessing the data pointer of &U

The last point being the difference to struct. This property holds for traits and slices and custom DSTs could opt into this property by implementing some unsafe trait.
Note that we would allow
union U<T: ?Sized> {
	t: ManuallyDrop<T>,
	u: (),
}

compile even though the behavior would be undefined if you could call size_of_val on an unsized U<ThinDst>. However, there would be no safe way to construct such a U because U<T> does not implement Unsize<U<ThinDst>>.

So basically, "fat DST" would work in unions but thin DST would not, by controlling which unsizing coercions the compiler permits?
Yeah, something like this could work. There might be semver concern here since now it matters whether an unsized type parameter is used below a union or not -- but maybe that is acceptable.


chore: add eslint with antfu's eslint config

Added eslint with antfu's config and also added the defaultFormatter for Code plus the extension recommendation.

updated my PR - should be good to merge now.


Fix ReadTheDocs to build using Python3.6 and install dependancies for autodoc

It seems that RTD uses Python2.7 by default, so autodoc failed with syntax errors.
This tells RTD to use Py3.6, and to also install our standard runtime dependencies so that we don't get import errors.
This is a best effort, so I hope it solves all the problems.

Pull Request Test Coverage Report for Build 62

0 of 0   changed or added relevant lines in 0 files are covered.
75 unchanged lines in 4 files lost coverage.
Overall coverage remained the same at 88.49%

Files with Coverage Reduction
New Missed Lines
%

tortoise/backends/base/executor.py
1
95.53%

tortoise/backends/asyncpg/schema_generator.py
3
100.0%

tortoise/backends/asyncpg/executor.py
9
100.0%

tortoise/backends/asyncpg/client.py
62
68.83%

Totals

Change from base Build 53:
0.0%

Covered Lines:
1608

Relevant Lines:
1765

💛  - Coveralls

Pull Request Test Coverage Report for Build 62

0 of 0   changed or added relevant lines in 0 files are covered.
75 unchanged lines in 4 files lost coverage.
Overall coverage remained the same at 88.49%

Files with Coverage Reduction
New Missed Lines
%

tortoise/backends/base/executor.py
1
95.53%

tortoise/backends/asyncpg/schema_generator.py
3
100.0%

tortoise/backends/asyncpg/executor.py
9
100.0%

tortoise/backends/asyncpg/client.py
62
68.83%

Totals

Change from base Build 53:
0.0%

Covered Lines:
1608

Relevant Lines:
1765

💛  - Coveralls

Hmm, it made it worse.  https://readthedocs.org/projects/tortoise-orm/builds/7500692/
It just failed, but no reason?

Ah, seems there is a RTD issue since yesterday:
https://github.com/rtfd/readthedocs.org/issues/4380


Adding script tag for production build?

I am having some trouble actually including the service worker in my project.  I can see the generated service-worker.js show up in the dist/ folder, but how do I go about actually including it?  If I  in my index.html, the build obviously fails the first time (and in CI since the build is 'fresh' every time) because service-worker.js does not exist yet.

How do you serve your static files (js,css, etc)?
You need do the same for the service-worker.js file and make sure the endpoint is /service-worker.js
Furthermore, you need to register the service worker, use the endpoint above.
This is not related to this repo. Take a look at this: https://github.com/cyyyu/firetodo/blob/master/src/register-service-worker.ts#L25

you don't need to point into index.html.
just to the same as I did in https://github.com/cyyyu/firetodo/blob/master/src/register-service-worker.ts
service worker is actually registered here:

Ah, ok!  Do you have a non-type script example perhaps?

I feel there is no ts features in that file. just rename to js and it should work.

Thanks.


(docs) no man page and no (-h) help option

After using this installation procedure (as root):
pip3 install --log-file ~/log/pip3-argostranslategui.err --log ~/log/pip3-argostranslategui.log --cache-dir /usr/local/pkgs argostranslategui
No man page was created.  And when running argos-translate-gui -h, the GUI app is launched without giving help output.  There should be a help page no matter how trivial it is so that users at least see that there are no options.  Some things that should be covered by the help page:

Since the GUI does take the liberty of connecting to the Internet (to download lang pairs), users would expect to see a --proxy option or absence thereof.

A “bugs” section to tell users where to report bugs.  (Which btw would ideally not force users to interact with MS Github.)

Information about where lang pair libs are stored, most particularly because this differs from the CLI version.

doc bug 2:
These installation instructions should tell users how to install it systemwide (as root) and how to install it individually for one user:
https://github.com/argosopentech/argos-translate-gui#install
ATM it makes no mention of root, but it should say to run as root if that’s the only way.  I know from experimentation that those instructions work for root but I’ve not tested as a user.
Those installation instructions should also disclose 2 sizes: the download size for bandwidth calculations (for those on measured rate connections) and the installation size after everything is unpacked.  Normal mainstream package managers (like aptitude) generally give users that info by design, but since pip3 is quite underdeveloped it does not give that info so it should be documented.
pip3 quietly dumps downloaded installation files in /tmp/ without telling users where the files are.  This is dicey particularly if the download is interrupted.  So I would propose suggesting use of the --cache-dir option to users.  It might sound like too much hand-holding, but pip3 is a developer tool -- it was never intended for normal users.  And pip3 is very poorly documented.  That is, the man page and help page are inconsistent with each other and with what the software does.

@PJ-Finlay are contributions still welcome? i'm getting into PyQt5 and i think i can contribute to both issues and add some minor improvements.

@PJ-Finlay are contributions still welcome? i'm getting into PyQt5 and i think i can contribute to both issues and add some minor improvements.

Definitely!
There are multiple issues mentioned here so please break them into separate pull requests.


Custom Engineering VKP80II

Has anybody got a Custom Engineering VKP80II to work properly on a Raspberry?
It works, but in a weird way, it's like: print-feed-print-feed-print-feed-print-feed ...
The feed seems to be one line, i.e. when printing out a completely black image, it looks like this:

Is there anything I can do about it? Custom engineering has Linux drivers, but only for X86 32/64bit, not Raspberry ARM architecture.

That was wrong, custom actually has drivers with ARM32 binaries that work on the Pi.
Can be downloaded here: https://www.custom4u.it/


PGPORT is not adhered to for tests

Contrary to the README/Makefile setting PGPORT makes no difference, port 5432 is always used. Please update the README/Makefile or better, allow PGPORT to work so postgres can be run on any port.

Can you point to where it says PGPORT? The correct port envvar is DEIS_DATABASE_SERVICE_PORT.

Ah I see what you mean. I'll be happy to update those.


Question: How can I disable the quize feature?

The quize feature is good, but I wonder how to turn off it. Sometime, it's just a bit annoying.

You can't at the moment. But we'll add options to disable that feature.


[.NET SDK] fix typo: Unkown => Unknown

@vacuum-car,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

@vacuum-car Would you please sign the license/cla, so we can accept this PR.  Thanks

@vacuum-car Thank you for catching this.
We've decided to accept https://github.com/Microsoft/BotBuilder/pull/3616 because that user has signed the license/cla.  For future pull requests, please sign the agreement.


[WIP]Bit 490 synapse fix

Pull Request Test Coverage Report for Build a61937a3-43ee-4182-881c-7d2eeeae33c4

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.03%) to 65.245%

Files with Coverage Reduction
New Missed Lines
%

bittensor/_threadpool/priority_thread_pool_impl.py
1
62.69%

bittensor/_subtensor/subtensor_impl.py
2
34.65%

Totals

Change from base Build e24a6c19-80cb-42a6-b039-0dffde5f1b0a:
-0.03%

Covered Lines:
3747

Relevant Lines:
5743

💛  - Coveralls


ecef_to_geocentric returns error when called with a Vector{Taylor1{Float64}}

Hi!
When trying to run
using SatelliteToolboxTransformations, TaylorSeries
v = Taylor1.(rand(3), 2)
ecef_to_geocentric(v)

the following error is returned:
ERROR: MethodError: no method matching AbstractFloat(::Taylor1{Float64})

Closest candidates are:
  (::Type{T})(::T) where T<:Number
   @ Core boot.jl:792
  AbstractFloat(::Int128)
   @ Base float.jl:269
  AbstractFloat(::Int16)
   @ Base float.jl:266
  ...

Stacktrace:
 [1] float(x::Taylor1{Float64})
   @ Base ./float.jl:294
 [2] float(::Type{Taylor1{Float64}})
   @ Base ./float.jl:311
 [3] ecef_to_geocentric(r_e::Vector{Taylor1{Float64}})
   @ SatelliteToolboxTransformations ~/.julia/packages/SatelliteToolboxTransformations/Gho81/src/reference_frames/geodetic_geocentric.jl:45
 [4] top-level scope
   @ REPL[6]:1

i.e., the error is coming from
https://github.com/JuliaSpace/SatelliteToolboxTransformations.jl/blob/b7790389407a207499d343aa6d546ef54990baa2/src/reference_frames/geodetic_geocentric.jl#L45
where the error occurs since Taylor1{Float64} cannot be converted to a float... maybe a possible fix can be to use promote_type somehow?

Btw, our current workaround is to overload this method for Vector{Taylor1{Float64}}, but then we incur in a slight type-piracy 🏴☠, which we would like to avoid 😅. Re: PerezHz/NEOs.jl#62

That said, beyond the possible type piracy, we would like to be able to use this function without having to re-write it (it's essentially the same code, but without the conversion to float), so we thought it'd be best to ask for help here 😅

Hi @PerezHz !
I really need that conversion to float to make the output type consistent (we use these algorithms with Float32 often to mimic what we have in the onboard computer). Hence, we have:
promote_type(Int32, Int64, Float32) |> float
Float32

Otherwise, the algorithm will be promoted to Float64 due to Int64.
I am still not sure what is the best approach. However, since Taylor1 seems to behave like a floating-point number for most of operations, what is the problem to define AbstractFloat(S::Taylor1{T}) where T<:Number = S? It should fix all problems as well.
julia> v = Taylor1.(rand(Float32, 3), 2)
3-element Vector{Taylor1{Float32}}:
  0.22708648 + 𝒪(t³)
   0.6600746 + 𝒪(t³)
   0.6802838 + 𝒪(t³)

julia> Core.AbstractFloat(S::Taylor1{T}) where T<:Number = S

julia> ecef_to_geocentric(v)
( 0.7725128686145345 + 𝒪(t³),  1.2394485 + 𝒪(t³),  0.9747065024345271 + 𝒪(t³))

Many thanks for the swift reply @ronisbr! Indeed, this seems in principle like a plausible solution on TaylorSeries side; I'd like to keep this issue open just in case things don't work out as expected if that's okay 😄

Fixed by JuliaDiff/TaylorSeries.jl#353, thanks @ronisbr!


Document relationship with cloud SDK genai client

Description of the feature request:
I found this library when searching for connecting to Gemini from Go. I was familiar with cloud.google.com/go/vertexai/genai and hadn't seen this yet, without thinking too much I thought perhaps it's a more idiomatic entry point to genai than the cloud SDK which are often close to auto-generated stubs (though I'm not sure this is the case for vertexai/genai specifically). But when trying to use the client with application default credentials like normal, using option.WithTokenSource, I couldn't get it to authenticate, even when trying scopes like https://www.googleapis.com/auth/generative-language. Eventually, I switched to vertexai/genai and had no problem. To my surprise, this was almost just replacing import statements, and one tweak to client initialization logic, which made me realize my hypothesis about the API being possibly more idiomatic wasn't correct.
I notice the docs for this project mention using an API key and don't mention application default credentials (yes I did try knowing the doc said "requires an API key" hoping it was a typo), other than that I'm not clear what the difference / use case for this project is. I guess my new hypothesis is it's meant to be for non-GCP users, while I've never thought to try it I guess "Google AI" is trying to be a purely AI product with decoupling from GCP. For GCP users, it's best to stick to the cloud SDK.
It would be nice to add documentation something like that, or otherwise whatever the case may be, to help prevent confusion for users that happen to find this while trying to use within GCP.
What problem are you trying to solve with this feature?
No response
Any other information you'd like to share?
No response

Thanks for the note. We're thinking about the topic of documentation more holistically now across the different SDKs and languages; I will keep this issue open for now

To elaborate on some of your observations:

There are two APIs because there are two products: one requires minimal auth and no GCP account; the other is designed for enterprise GCP users with GCP projects, billing, and so on. That is why the auth is different. We worked hard to make the API surfaces as close as possible.

We also worked hard to make them idiomatic Go, and to raise the level over direct RPCs to the service. We use the generated API as a base, then wrap protobuffers, rename, and perform other changes and additions to provide what we hope is an idiomatic and pleasant coding experience. The chat API is an example of raising the level above the raw RPCs.

Thanks @jba - I hadn't realized there's actually two APIs with similar surfaces, which is clarifying. BTW, I didn't mean to indicate the APIs aren't idiomatic, I found them easy enough to use, I was just surprised to see the match against the GCP SDK's client, which I'm used to not having such usability in other services ;)
I suspect just a line such as this at the top of the docs would help a lot. "Generative AI" is a general term so I think it's easy to expect this repo to apply to vertex AI as well and cause confusion.
This SDK is for the Google AI Studio. Google Cloud Platform Vertex AI users should use the [Google Cloud SDK](https://pkg.go.dev/cloud.google.com/go/vertexai/genai) instead.


fix(mouse): zoom limitation

currently, zoom on mousewheel is not working for huge diagrams (e.g. Performance story).
the reason is the minimum zoom we check for before setting it.
Any zoom level equals and above 1 is valid for transform values.

:tada: This PR is included in version 3.0.6 :tada:
The release is available on:

npm package (@latest dist-tag)
npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


StorageDisk Exception

I have a problem with StorageDisk.When i run the app in the first time, it will create files that is tomp2p and tomp2p.p on local filesystem, everything is ok, but when i run the app again, it reported a exception like below:
Caused by: java.lang.RuntimeException: Could not instantiate class
            at org.mapdb.SerializerPojo.deserializeUnknownHeader(SerializerPojo.java:483)
            at org.mapdb.SerializerBase.deserialize3(SerializerBase.java:1216)
            at org.mapdb.SerializerBase.deserialize(SerializerBase.java:1132)
            at org.mapdb.SerializerBase.deserialize(SerializerBase.java:867)
            at org.mapdb.SerializerPojo.deserialize(SerializerPojo.java:701)
            at org.mapdb.BTreeMap$NodeSerializer.deserialize(BTreeMap.java:449)
            at org.mapdb.BTreeMap$NodeSerializer.deserialize(BTreeMap.java:288)
            at org.mapdb.Store.deserialize(Store.java:297)
            at org.mapdb.StoreDirect.get2(StoreDirect.java:475)
            at org.mapdb.StoreDirect.get(StoreDirect.java:428)
            at org.mapdb.Caches$HashTable.get(Caches.java:245)
            at org.mapdb.EngineWrapper.get(EngineWrapper.java:58)
            at org.mapdb.BTreeMap.<init>(BTreeMap.java:541)
            at org.mapdb.BTreeMap.preinitCatalog(BTreeMap.java:178)
            at org.mapdb.DB.reinit(DB.java:88)
            at org.mapdb.DB.<init>(DB.java:83)
            at org.mapdb.DBMaker.make(DBMaker.java:668)
            at net.tomp2p.storage.StorageDisk.<init>(StorageDisk.java:85)
            at org.hive2hive.mobile.test.MapDBTestActivity.onCreate(MapDBTestActivity.java:39)

I just wanna do some work of restoring data, then i test the StorageDisk class(it almost a single opration of newing StorageDisk(...)),it's ok on pc but seems not work on android.
this is the source code:(it's very simple)
File path = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);
path.mkdir();
SignatureFactory signatureFactory = new RSASignatureFactory();
storageDisk = new StorageDisk(Number160.createHash("test1"), path, signatureFactory);

I fully replaced old StorageDisk (on top of MapDB) by StorageBerkeleyDB (on top of BerkeleyDB), which works on Android and PC well. You can see my impl in https://github.com/ChronosX88/Influence-android


Import study error

I inadvertently I had a few weird characters in my json data, like in the image below.
This led to database importing errors, and didn't let me import the study

After long searches, the solution was:
take my json string, pass it through here: http://coderstoolbox.net/string/#!encoding=xml&action=decode&charset=utf_8
and then copy it into word, where the non-unicode characters are displayed (copying it directly into word reveales some, but not all non-valida characters). Remove the (?) (it's actually a little square with a question mark in it) and then copy them back in.
Is there a way that the submit button could also check for non-unicode characters so this doesn't happen? Would this also happen if the problem is in the 'comments' box, where no json is required?

It's MySQL's UTF-8 encoding. You created and exported your study locally with JATOS running a H2 database - but the JATOS you wanted to import your study to is using MySQL database. MySQL has trouble handling UTF-8 characters if they have more then 2 bytes. For more details here or here.
Possible solutions are:

Use H2 databases on your server
If you already have a MySQL database, change your encoding to utf8mb4 like described here or here


Update page

[Enter feedback here]
This doc has not been updated since the end of 2019. Microsoft Teams should be added here as part of the workload if its a Medium or Heavy workload.
Thanks,

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 005d4eb3-89ee-3251-f104-f7cbfcbd3757
Version Independent ID: 80c55a08-3bc5-dca5-a33c-2051202d5288
Content: Remote Desktop workloads
Content Source: WindowsServerDocs/remote/remote-desktop-services/remote-desktop-workloads.md
Product: windows-server
Technology: remote-desktop-services
GitHub Login: @Heidilohr
Microsoft Alias: helohr

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


Updated event summary to include refund finances and differentiate between pending and completed payments.

@nmorduch I think this resolves the event summary page display for now - did you want to include the order summary improvements as part of this ticket / include changes there? The data should now all be available. If there's anything missing let me know.

Before I do this, does it work with the new internationalization?

Yes, it should. Stripe charges use the event's currency, which was already changeable. The only "internationalization" that I did was actually displaying the correct country and currency on the event settings page.

So this works as well as what we already had.

Closes #292

I did this using rebase in the command line and the commit went onto master but github thinks this branch is not merged. Did I do something wrong? I normally just merge using the button that says merge, but I didn't want the merge commit that comes with that.

If you're merging from the command line, you do git merge <branch> --no-ff from the master branch. This makes a merge commit to show that a branch was merged. Rebase just sticks the branch on the end of the master branch as if it had always been there. If you then merge without --no-ff, the master fast-forwards.
Generally speaking, we want to have merge commits.

But if we always have a new branch for every little thing, then that's a million merge commits.
What should I do to remedy this now?

Meh, just delete the branch.


Unpin protobuf

The version pinned here is ancient, and causing this feedstock to miss already several protobuf migrations. 3.20 is completely unsupported in conda-forge these days, and so the packages produced here will become less and less installable.
Given that this package has the right dependency on libprotobuf (i.e. you can generate whatever protobuf's with the correct version), it's very likely that the upstream pin is completely unnecessary, and just defensive on the side of the upstream developers, because it's really painful to handle on PyPI.
Given that some people want to run pip check, this should simply be patched out. Ideally combined with running the upstream test suite, so we ensure everything still works fine.
CC @conda-forge/mysql-connector-python @bollwyvl

If the context provided in the commit message of https://github.com/mysql/mysql-connector-python/commit/07e3d17dc4dcea16f79a8e8364328926f0afc9ff is not going to be an issue in the conda-forge ecosystem, feel free to open a pull request :)

Agreed that upstream would need to own the underlying issue more fully for it to be fully resolved.
For here: patch and test sounds like a solid way forward. Perhaps with the extras as named packages, one could even sneak in a few more test excursions (e.g. epoch versions of protobuf).

If the context provided in the commit message of mysql/mysql-connector-python@07e3d17 is not going to be an issue in the conda-forge ecosystem, feel free to open a pull request :)

It sounds a bit nonsensical to me. The protobuf python bindings and protoc obviously go together. However 4.21.0 was the very first release with the new protobuf versions scheme, and it might have just been a regular bug as well... I don't know this feedstock, but if there's an upstream test suite to run (and we pass it), I really wouldn't worry. If there's no good test suite, I wouldn't want to risk it though.


Support ! in pipeline

This should work:
arg =
    Arg.list!
    |> List.get args 1
    |> Result.withDefault "No command line args provided."

But it is not implemented yet, currently you need to do:
args = Arg.list!

arg =
    List.get args 1
    |> Result.withDefault "No command line args provided."

! only works with Task.await. The plan is to wait and see how that works out first. We may not implement it for Result as discussed in the proposal.

@lukewilliamboswell Arg.list is supposed to be a Task.
Zulip thread

Thank you @wontem.
This should be working. I'll do some investigation.

Additional investigation

@wontem fixed the unwrapping of ! operator in #6777, the parsing issue remains.


LeaderBoard: Feature/setup_project

I have done the following changes and I want to implement these:

[x] Created a new repo.
[x] Created dev and feature branches using Gitflow.
[x] Setup Linters.
[x] Setup Webpack.
[x] Created index.html
[x] Created index.js
[x] Created styles.css
[x] Created README.md
[x] Fixed Linters Errors
[x] Loaded App using webpack
[x] Created dist folder with webpack.
[x] Unable to fix Webhint Errors (Please excuse me for that).

This webhint error is not going away, dont know why. Could you please excuse me for that?


SSL Enabled Kafka Cluster is Not Working

Hello All ,  We are using kafdrop-2.0.0.jar and Seems to be accessing ssl enabled kafka cluster is not working.
java -jar kafdrop-2.0.0.jar --zookeeper.connect=localhost:2181/kakfa
Am i missing any Params here ?
Same command works for PLAINTEXT.
Kafka Version : 0.11.0

Pong? GOt any workaround ?

no :(

facing the same issue, any solutions found??

Facing the same issue. Any leads?

Kafdrop 3 supports both SSL/TLS and SASL.
There is no real development taking place on Kafdrop 2.x. Consider updating to the next major version – Kafdrop 3.


Cannot open the link "https://archive.org/details/FSC147-GT"

Hi, I can't open this link https://archive.org/details/FSC147-GT, Is anyone who can provide the BaiduNetdisk's link???

I have the same problem

I have the same problem


fs: Fix buffer overflow when LFN is enabled with FATFS

This PR creates a test case for calling fs_stat, fs_open and fs_close on a file with a long file name. (though it does not exhaust the 255 length). This also includes the fix to resolve the buffer overflow observed in #25710. There is also a fix in an adjacent test case that used a hard coded path length of 80l.
fixes #25710

What @pabigot said makes sense. Nothing else from my side :)

Close and re-open in attempt to kick buildkite into retesting.

@NZSmartie Please rebase this on current master so the buildkite process can see a configuration that will actually work.


[BUG] - Tooltip not working with onClick() Event in custom Table

NextUI Version
2.3.6
Describe the bug
Related to:

https://nextui.org/docs/components/table#custom-styles

I'm not able to define a Tooltip programatically via onClick() event inside of your custom table example. I will pass here the relevant part of my code because posting the full table would be too much code:
export default function TransactionsTable() {
	 const [tooltipId, setTooltipId] = useState<string | null>(null)

	 const copyAddress = (value: string, id: string) => {
	        navigator.clipboard.writeText(value)
	        setTooltipId(id)
	    }

	const renderCell = useCallback((transaction: Transaction, columnKey: React.Key) => {
	        const cellValue = transaction[columnKey as keyof Transaction]

	        switch (columnKey) {
	        case 'from':
	            return (

{transaction.from.substring(0, 6) + '...'}

	                    <Tooltip
	                        isOpen={tooltipId === transaction.hash}
	                        content="Copied!">

	                        <button
	                            style={{ marginLeft: '0.2rem' }}
	                            onClick={() => copyAddress(transaction.from, transaction.hash)}
	                            className="ml-2 flex items-end">
	                            <CopyClipboardIcon />
	                        </button>

	                    </Tooltip>

	            )

	        default:
	            return cellValue
	        }
	}, [tooltipId])
}

The code itself is working. When I click on the top right on the columns button to add a new column then I can see my tooltip. This means tooltipId was successfully changed but will only get recognized when the Table component recieves any element update/change.
I'm new to react but I guess it has to do with the useMemo() or useCallback() React parts in your table example. However, I gwas guessing that passing [tooltipId] to the renderCell() would solve the problem because as far as I understand React Hooks this way it will detect variable changes and reload the context of the hook.
But in this case it is not working. I tried almost everything including try to Force Reload it with forceRender()
const [, forceRender] = useReducer(x => !x, true)

Which is also not working.

Am I missing something? Also in your Tooltips docs page I did not find any suitable example for programatically defining tooltips. Maybe I doing something wrong? Is there an official way?
If I use this then it is working:

https://nextui.org/docs/components/popover

Also another question, when I use the table with selectionMode:multiple then my custom copy clipboard button is working but the z-index of the selected row will always win. I tried to set my button z-index higher but it does not work. Is it even possible to win the z-index race with a custom button inside of your row?
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
https://nextui.org/docs/components/table#custom-styles
Expected behavior
Tooltip working with onClick() inside your custom table example
Screenshots or Videos
No response
Operating System Version
Linux
Browser
Chrome

Hi @CyberT33N,
Try playing around with Button component's onPress event.
Link:
https://nextui.org/docs/components/button#button-events


Cannot add finder

I tried adding a finder but i'm getting a type error.
I assumed it was something wrong with my code, but when just pasting the example from the docs i get the same error:
The type 'IWebDriver -> IWebElement list' does not match the type 'IWebElement list'
module Finders

open canopy.classic
open OpenQA.Selenium

let findByHref href f =
    try
        let cssSelector = sprintf "a[href*='%s']" href
        f(By.CssSelector(cssSelector)) |> List.ofSeq
    with | ex -> []

addFinder findByHref

For information, the selector i want to add is a lookup by data-attributes like this:
click "data-tab=properties
should select the element
<div class="tab" data-tab="properties"
Here is my selector as i wrote it:
module Finders

open canopy.classic
open System.Text.RegularExpressions
open OpenQA.Selenium

exception FinderDoesNotApply of unit

addFinder ( fun dataAttribute f ->
    try
        if Regex.Match(dataAttribute, "^data-\w{1,}=\w{1,}").Success then
            let selectorParts = dataAttribute.Split [|'='|]
            let selector = "*[" + selectorParts.[0] + "=\"" + selectorParts.[1] + "\"]"
            f(By.CssSelector(selector)) |> List.ofSeq
        else
            raise (FinderDoesNotApply())
    with | ex -> []
)

I figured it out. The documentation is outdated. Adding a third (unused) parameter to the function solves it:
module Finders
open canopy.classic
open System.Text.RegularExpressions
open OpenQA.Selenium

exception FinderDoesNotApply of unit

let dataFinder dataAttribute f _ =
    try
        if Regex.Match(dataAttribute, "^data-\w{1,}=\w{1,}").Success then
            let selectorParts = dataAttribute.Split [|'='|]
            let selector = "*[" + selectorParts.[0] + "=\"" + selectorParts.[1] + "\"]"
            f(By.CssSelector(selector)) |> List.ofSeq
        else
            raise (FinderDoesNotApply())
    with | ex -> []

Yes, I didnt realize the documentation was out of date.  Here is an example:
https://github.com/lefthandedgoat/canopy/blob/273fe1c5e93111d5114e2ef81e1d02e9e3eaf49b/tests/basictests/Program.fs#L739-L747

Thank you for the prompt reply even though i solved the issue.
Loving canpoy :)


db: add undo support

Codecov Report

Merging #110 into master will decrease coverage by 0.47%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #110      +/-   ##
==========================================
- Coverage   92.81%   92.34%   -0.48%
==========================================
  Files          64       64
  Lines        2688     2690       +2
==========================================
- Hits         2495     2484      -11
- Misses        193      206      +13

Impacted Files
Coverage Δ

db/changes.js
97.82% <100%> (-2.18%)
:arrow_down:

db/extend.js
69.53% <0%> (-4.69%)
:arrow_down:

db/map.js
79.78% <0%> (-3.2%)
:arrow_down:

db/group.js
78.9% <0%> (-2.35%)
: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 8f45c27...f14bcce. Read the comment docs.


Badge hiding behind view.

I am trying to append badgehub onto a UIImageView. The badge is appearing however when it reaches the corner; it stays behind the imageview or view and just hides away.
I tried setting the z-index however that doesn't seem to be affecting anything. Anyone else having this issue? Or found a solution. Cheers
let hub = BadgeHub(view: cell.contentView) // Initially count set to 0
hub.hubView?.layer.zPosition = 10000
hub.increment()

I'm having the same issue ... did you find a fix @Harryjeffs ?

@lcolli98 Hey! I posted to stackoverflow, and found the answer myself - https://stackoverflow.com/questions/61298622/uicollectionviewcell-badge-masked-behind-view.
Issue was how I was rounding the corners. Let me know if this helps you too :)

That isn't working for me ... any ideas?
button2Image is a UIImageView on top of a UIButton, button2. The badge is being appended to the image view. I've tried manually changing the Z position, ensuring it is first in the storyboard, and bringSubviewToFront, but still no luck.
The image view doesn't have rounded corners (the button does, but the badge should easily be contained within the button).

@lcolli98 Mind sharing some code so we can help debug?

@IBOutlet weak var titleLabel: UILabel!
    @IBOutlet weak var button1: UIButton!
    @IBOutlet weak var button2: UIButton!
    @IBOutlet weak var button2Image: UIImageView!
    @IBOutlet weak var button3: UIButton!
    @IBOutlet weak var button4: UIButton!
    @IBOutlet weak var userAccButton: UIButton!

    override func viewDidLoad() {
        super.viewDidLoad()

        // Set the title text based on whether logged in or not
        /*
         if (loggedIn) {
            titleLabel.text = "Welcome back, <name>"
         } else {
            titleLabel.text = "Welcome to AeroBuddy"
         }
         */

        // Setup user account button
        userAccButton.layer.cornerRadius = 0.5 * userAccButton.bounds.size.width
        userAccButton.clipsToBounds = true
        userAccButton.layer.borderWidth = 2
        userAccButton.layer.borderColor = UIColor.lightGray.withAlphaComponent(0.6).cgColor

        // Set the news notifcation bubble - see https://iosexample.com/a-way-to-quickly-add-a-notification-badge-icon-to-any-view/
        // Use newsBubble.increment(), newsBubble.decerement(), newsBubble.setCount(newCount: Int) to control
        self.view.bringSubviewToFront(button2Image)
        let newsBubble = BadgeHub(view: button2Image)
        if (false /* no unread news */) {
            newsBubble.setCount(0)
        } else {
            // Set the amount of unread news articles
            newsBubble.setCount(1)
            //self.view.bringSubviewToFront(button2Image)
            newsBubble.bump()
        }
    }

That's the view controller where everything is displayed.

@Harryjeffs did you manage to take a quick look? I still haven't figured it out yet :/

For anyone else with this issue ... I added a transparent UIView over the top of the button and added the BadgeHub to that. This works.


Execute function before focusing on first erroneous input

it would be very useful to be able to execute some actions before focusing in the first error.
Like showing a message to the user.
Or adding a message for Screen Reader users (to be compatible with WCAG)

I don't know if this is helpful for you, but you can specify a custom scroll to function.

you are right, I didn't see that option


Route ID can't be edited in canvas

Describe the Bug
The route ID edition in the canvas is not stored.
Steps to Reproduce the Bug or Issue

Create a route
in canvas - try to perform the route ID edit
see no changes

Screenshots or Videos

Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [latest]

Hi @tplevko, for this ticket, I think we would need to define a new method in the CamelResource interface, perhaps setFlowId or another name that you see fit better and then implementing it on each resource.
The method could look like the following:
setFlowId(oldId: string, newId: string): void {
  // implementation goes here
}

After that, we can use said method in the FlowList component, here


Podman pull fails with short name (rhel-tools)

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug

Not sure if this would be considered a bug

/kind feature

Perhaps this might be expected behavior, so I think it's a feature :-)
Description

Steps to reproduce the issue:
podman pull rhel-tools
Trying to pull registry.access.redhat.com/rhel-tools:latest...Failed
Trying to pull registry.fedoraproject.org/rhel-tools:latest...Failed
Trying to pull docker.io/rhel-tools:latest...Failed
Trying to pull <IP_ADDRESS>/16/rhel-tools:latest...
Also, broken in docker:
[root@rhel7 ~]# docker pull rhel-tools
Using default tag: latest
Trying to pull repository registry.access.redhat.com/rhel-tools ...
Trying to pull repository registry.access.redhat.com/rhel-tools ...
Trying to pull repository registry.fedoraproject.org/rhel-tools ...
Trying to pull repository docker.io/library/rhel-tools ...
Trying to pull repository docker.io/library/rhel-tools ...
repository docker.io/rhel-tools not found: does not exist or no pull access.
I also tried:
podman pull rhel7/rhel-tools
Trying to pull rhel7/rhel-tools...Failed
error pulling image "rhel7/rhel-tools": unable to pull rhel7/rhel-tools: unable to find image in the registries defined in "/etc/containers/registries.conf"
The full URL works thougth:
podman pull registry.access.redhat.com/rhel7/support-tools
Trying to pull registry.access.redhat.com/rhel7/support-tools...Getting image source signatures
Skipping fetch of repeat blob sha256:313bb043666e4db013cc092b56725bb3230f4b95b36cc736b3629cb5452d28f0
Skipping fetch of repeat blob sha256:514c0a80c7bf58a39d2f6e91cac18fd85aa6ad78f4bc341b14cbc8386af69306
Skipping fetch of repeat blob sha256:04127453b413b3678586af6bac66b9c4cfaa94d12066ae009daec955ce03ba79
Copying config sha256:5991cf94beed33f6b86a44c4b22495905a265af0fda8b18207461dbffdb5433e
4.12 KB / 4.12 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
5991cf94beed33f6b86a44c4b22495905a265af0fda8b18207461dbffdb5433e
Describe the results you received:
Podman fails to find the image
Describe the results you expected:
I expect it to find the image and pull it :-)
Additional information you deem important (e.g. issue happens only occasionally):
Also, happens in docker, so not sure if it's client side or registry side
Output of podman version:
podman version
Version:       0.7.3
Go Version:    go1.9.2
OS/Arch:       linux/amd64

Output of podman info:
host:
  MemFree: 378826752
  MemTotal:<PHONE_NUMBER>
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 1
  hostname: rhel7.dc2.crunchtools.com
  kernel: 3.10.0-862.9.1.el7.x86_64
  os: linux
  uptime: 100h 1m 25.61s (Approximately 4.17 days)
insecure registries:
  registries: []
registries:
  registries:
  - registry.access.redhat.com
  - registry.fedoraproject.org
  - docker.io
  - <IP_ADDRESS>/16
store:
  ContainerStore:
    number: 4
  GraphDriverName: overlay
  GraphOptions:
  - overlay.override_kernel_check=true
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 13
  RunRoot: /var/run/containers/storage

Additional environment details (AWS, VirtualBox, physical, etc.):
This is on a fully updated Red Hat Enterprise Linux Server release 7.5 (Maipo) - packages current as of 08/30/2018

Also, here is anther example with the rhel base image. I think it's a two part failure:
https://pastebin.com/1eb3waja

I can't reproduce with other images but I also don't have a login on Red Hat's registry. Are you logged into registry.access.redhat.com?

No any image with a REPO/image is failing because of the parser.  I have a fix for this.


Write a test-suite with source/expected outputs.

We come across a number of edge case when parsing pieces of RST, so we do have custom logics.
Currently we rerun papyri on all of numpy/scipy and make sure it does not crash.
A better test harness would have a number of example snippets, and expected AST tree, and the test suite should compare that we are not regressing.
We should also have an easy to reach command line when the examples are wrong, and need to be updated.

This has been started as part of #177

Make sure to mock contents so there is no required installation/generation/ingesting of real modules before running test suite.


Embed monospaced font

Qt does not guarantee that the actual applied font matches to the requested one.
It was noted (https://github.com/bitcoin/bitcoin/pull/16432#issuecomment-514486077):

the monospace font looks a bit weird no macOS

... because it is not monospaced.
Also some discrepancies I've noted on Windows while testing Qt 5.15 (#19716).
Of course, we could check the actual font with QFontInfo, and try to choose another font.
But this PR suggests to just embed a monospaced font, and get the GUI look (partially) independent from a platform.
Roboto Mono was chosen after discussion with Bitcoin Design community, and due to its Apache License, Version 2.0.
Changes are scoped to the Overview page only.

Screenshots on macOS 10.15.6 (images are simulated by code patching):

master (ca30d34cf94b7797272ef1920ca4b48716e7f999)

this PR (3fdd5b6bd17a679d6e3876682266092159c52d59)

Many thanks to @GBKS !

Before and after screenshots on various OS's would be nice.
I'm generally not a fan of messing with the default font choices of operating systems / desktop environments. However, if upstream QT doesn't use a proper monospaced font for macOS, then it makes sense for at least that platform.

Just for record: another PR that embeds a font is https://github.com/bitcoin/bitcoin/pull/16883.

Another suggestion https://fonts.google.com/specimen/Roboto+Mono

There have been concerns about OFL Licensing in the past...
https://github.com/bitcoin/bitcoin/pull/17311#issuecomment-550453875
https://github.com/bitcoin/bitcoin/pull/17311#issuecomment-550591089
But if OFL isn't an issue - then fonts-liberation is a good candidate as well.
https://en.wikipedia.org/wiki/Liberation_fonts

Looking for Concept (N)ACKs (plus comments if you have them) from designers cc @GBKS @Bosch-0 @johnsBeharry

Concept (N)ACK
Using Roboto Mono would be a better alternative:

IBM Plex Mono uses a OFL license which as pointed out in https://github.com/bitcoin/bitcoin/pull/17311#issuecomment-550591089 has some concerns about its 'free' status.  Roboto mono uses Apache Licence, Version 2.0 which as far as I'm concerned isn't an issue.

Roboto Mono is a variable font which allows it to have its properties changed (weight, width etc.) without needing a separate font file. This will keep the overall font file size down.

This may be a subjective take but I think Roboto Mono is also slightly more readable.

IBM Plex Mono

Roboto Mono

About font sizes:
$ ls -go
total 380
-rw-rw-r-- 1 111532 Mar 11  2018 IBMPlexMono-Medium.ttf
-rw-rw-r-- 1  86820 May 13  2015 RobotoMono-Medium.ttf
-rw-rw-r-- 1 182172 May 13  2015 RobotoMono-VariableFont_wght.ttf

Hebasto asked in slack whether choosing # or * would be more applicable for hidden/masked amounts. I'd go for the star * over the hash #, it looks cleaner (see below). Each item being concealed should also used a fixed number of strings as @achow101 pointed out here - I used 9 here so it fills the same amount of space as the unconcealed items. Having a fixed number of strings also gives consistency resulting in a cleaner UI.

I also did a design for the suggestion that @promag made regarding having a toggle icon on the overview page that users can click on to easily turn privacy mode on or off. Does privacy mode conceal any information in the send, receive or transactions sections? I think this mode could be extended to those areas also if not. If so this toggle could be moved to the top menu, possibly to the left of the wallet selection drop down.

It appears that Qt (at least 5.12.8) cannot work with variable fonts.
At least QFont::setWeight() is noop for RobotoMono-VariableFont_wght.ttf.

Ahh that's a shame, not a huge issue though, as the mono font is only going to be used in a few places the benefits of using a variable font is negligible. The static medium Roboto Mono font style should be all we need to use.
I think the licensing issue with OFL still makes Roboto Mono a more suitable option than IBM Plex Mono.

Updated 15f37db53124f31d5499ce0604f907b9564aa506 -> 3fdd5b6bd17a679d6e3876682266092159c52d59 (pr79.01 -> pr79.02, diff):

used Roboto Mono instead of IBM Plex Mono as requested by @Bosch-0
changes are scoped only the Overview page as it is a clear visual bug fix

Going to update OP soon.

@Sjors

Before and after screenshots on various OS's would be nice.

Done.

I'm generally not a fan of messing with the default font choices of operating systems / desktop environments. However, if upstream QT doesn't use a proper monospaced font for macOS, then it makes sense for at least that platform.

This is under discussion now in Bitcoin Design Community (https://github.com/BitcoinDesign, https://bitcoindesign.slack.com). Please join the discussion :)

Concept NACK to overriding the platform. If users don't like their platform's font choices, they should change it there.
Also concept NACK to moving discussion to a private proprietary platform.

I agree with @luke-jr that the bitcoin design community should not require Core contributors to join Slack in order to debate changes to the Core GUI (although developers are more than welcome to join the conversation there!). I think it is fine if there is discussion on Slack or video calls or any medium, but for any kind of formal proposal or discussion or debate, it should occur on GitHub as that is the existing process for the project.

Just my two cents for the screenshot in the OP: Using monospace for the balance numbers seems like a weird workaround (weird because you have two different fonts for the same line of information, the label in the normal UI font and then the number & unit in the monospace one). It would be much nicer to use a non-monospace font throughout that supports tabular figures (see https://www.fonts.com/content/learning/fontology/level-3/numbers/proportional-vs-tabular-figures). Or doesn't that work in Qt?

@flack

Just my two cents for the screenshot in the OP: Using monospace for the balance numbers seems like a weird workaround (weird because you have two different fonts for the same line of information, the label in the normal UI font and then the number & unit in the monospace one). It would be much nicer to use a non-monospace font throughout that supports tabular figures (see https://www.fonts.com/content/learning/fontology/level-3/numbers/proportional-vs-tabular-figures). Or doesn't that work in Qt?

Thanks! TIL. I didn't know about "tabular figures".

@hebasto -
The Roboto Family is an excellent choice as an embedded font (imo).
I believe we should be proactive and embed the entire family.
It would eliminate this unknown factor in Gui design moving forward.
Keep in mind -  fonts do pose a security issue.
https://www.zdnet.com/article/google-open-sources-internal-tool-for-finding-font-related-security-bugs/
https://security.stackexchange.com/questions/91347/how-can-a-font-be-used-for-privilege-escalation
In essence - embedding fonts explicitly enhances determinism.

@luke-jr

Concept NACK to overriding the platform. If users don't like their platform's font choices, they should change it there.

Being a financial application the Bitcoin Core requires a monospaced/fixed-pitch font (or, at least, tabular figures font).
The Qt's font matching algorithm does not guarantee that:

the monospaced font will be chosen at all (see https://github.com/bitcoin/bitcoin/pull/16432#issuecomment-514486077)
the chosen monospaced font has expected style and weight (see https://github.com/bitcoin-core/gui/pull/87#issuecomment-768920736)
an upgrade of the system or Qt won't change the Bitcoin Core look unexpectedly

A agree that user's ability to customize fonts is good. The question is how users could customize the monospaced font for Qt application now?
I'm not aware of such possibilities on Windows 10 and macOS 11.1. On Linux I used the qt5ct package, but it fails to customize the monospaced font.
If there are no ways to customize the monospaced font for Qt application, are you going to insist on your point?

The Roboto Family is an excellent choice as an embedded font (imo). I believe we should be proactive and embed the entire family.

Despite really disliking it on a conceptual level, I think 'ship your own fonts' is the modern way. The less assumptions we have to make about the operating system, platform, and what is already installed, the better.

Concept NACK to overriding the platform. If users don't like their platform's font choices, they should change it there.

If this purely a design choice (there are no negative side effects to this change) I'm happy to leave to the designers. If the designers are a Concept ACK I'm a Concept ACK.

Code review and license review ACK 3fdd5b6bd17a679d6e3876682266092159c52d59
Please do update contrib/debian/copyright to explitily list the apache license for the embedded font files.

Concept ACK 3fdd5b6bd17a679d6e3876682266092159c52d59 - please add the license attribution

The Qt's font matching algorithm does not guarantee that:

the monospaced font will be chosen at all (see bitcoin/bitcoin#16432 (comment))
the chosen monospaced font has expected style and weight (see #87 (comment))

We already have functional workarounds for these.

an upgrade of the system or Qt won't change the Bitcoin Core look unexpectedly

That's desirable and expected behaviour.

I'm not aware of such possibilities on Windows 10 and macOS 11.1.

Crazy. It looks like Windows 10 removed the ability for users to configure their fonts. But that's a Windows problem, not necessarily ours...
I'm not surprised Apple denies users choice.

On Linux I used the qt5ct package, but it fails to customize the monospaced font.

It's right there in System Settings for me, as a "Fixed width" font choice.

🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

Updated 3fdd5b6bd17a679d6e3876682266092159c52d59 -> 67f26319a0ca7e34e3db17d9330133622a40de09 (pr79.02 -> pr79.04):

rebased due to tyhe conflict with #115
added the license attribution as requested by @laanwj and @jonasschnelli
added an option to opt-out embedded monospaced font in Menu -> Options-> Display as requested by @luke-jr (as I understand his idea)

added an option to opt-out embedded monospaced font in Menu -> Options-> Display as requested by @luke-jr (as I understand his idea)

That seems like a reasonable compromise.
Can you also not add the font to the repo, make it optional at build time (perhaps configurable?), and bundle it via depends?

Can you also not add the font to the repo, make it optional at build time (perhaps configurable?), and bundle it via depends?

What reasons do you see for that?

So that people who don't want this can build without it...

Tested ACK 67f26319a0ca7e34e3db17d9330133622a40de09
A configure option to build without internal fonts can be added later. IMO adding the font to the repository itself is fine. It's only 87kB, not worth the overhead of an external depends download.

I'm a little confused, what version is the "before" picture from? I'm running 0.21 and it's already a fixed font.

@rebroad

I'm a little confused, what version is the "before" picture from? I'm running 0.21 and it's already a fixed font.

I suppose your system is not macOS, right?


Feature: RTL

Implement right-to-left feature, with the rightToLeft prop. Fixes #49
Add prependMostRecent prop, to be able to choose to which side to flicker when scrolling. See #39

Thanks @pdpino , It's working great! I'm merging.


Folder Settings could just open workspace settings in no-MRU workspace

testing https://github.com/Microsoft/vscode/issues/30722
insiders 1.15.0 9a308d11
in a non-multi-root workspace instance, opening the command palette and choosing "Preferences: Open Folder Settings" results in an info message:

In a multi-root workspace, this opens the settings for the folder.
Is there a reason we don't simply open the workspace settings in the non-MRW scenario?  It would be one less message for the user.

Folder settings are not same as Workspace settings. Opening workspace settings in one case and folder settings in another case will be confusing. It would be same as Opening workspace settings in an empty workspace scenario.


requirements.txt 中的tensorflow==1.15.0rc1 这个版本在https://pypi.tuna.tsinghua.edu.cn/simple找不到了

描述问题
requirements.txt 中的tensorflow==1.15.0rc1 这个版本在https://pypi.tuna.tsinghua.edu.cn/simple找不到了
日志：
[root@localhost 12306-master]# pip3 install -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt.new --
WARNING: Running pip install with root privileges is generally not a good idea. Try pip3 install --user instead.
Collecting tensorflow==1.15.0rc1 (from -r requirements.txt.new (line 1))
Could not find a version that satisfies the requirement tensorflow==1.15.0rc1 (from -r requirements.txt.new (line 1)) (from versions: 0.12.1, 1.0.0, 1.0.1, 1.1.0rc0, 1.1.0rc1, 1.1.0rc2, 1.1.0, 1.2.0rc0, 1.2.0rc1, 1.2.0rc2, 1.2.0, 1.2.1, 1.3.0rc0, 1.3.0rc1, 1.3.0rc2, 1.3.0, 1.4.0rc0, 1.4.0rc1, 1.4.0, 1.4.1, 1.5.0rc0, 1.5.0rc1, 1.5.0, 1.5.1, 1.6.0rc0, 1.6.0rc1, 1.6.0, 1.7.0rc0, 1.7.0rc1, 1.7.0, 1.7.1, 1.8.0rc0, 1.8.0rc1, 1.8.0, 1.9.0rc0, 1.9.0rc1, 1.9.0rc2, 1.9.0, 1.10.0rc0, 1.10.0rc1, 1.10.0, 1.10.1, 1.11.0rc0, 1.11.0rc1, 1.11.0rc2, 1.11.0, 1.12.0rc0, 1.12.0rc1, 1.12.0rc2, 1.12.0, 1.12.2, 1.12.3, 1.13.0rc0, 1.13.0rc1, 1.13.0rc2, 1.13.1, 1.13.2, 1.14.0rc0, 1.14.0rc1, 1.14.0, 2.0.0a0, 2.0.0b0, 2.0.0b1)
No matching distribution found for tensorflow==1.15.0rc1 (from -r requirements.txt.new (line 1))

我试着用了tensorflow2.0.0a0， 然后再运行应用的时候 报错了。
详细如下：
[root@localhost 12306-master]# python run.py
Using TensorFlow backend.
/usr/local/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:523: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint8 = np.dtype([("qint8", np.int8, 1)])
/usr/local/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:524: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_quint8 = np.dtype([("quint8", np.uint8, 1)])
/usr/local/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:525: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint16 = np.dtype([("qint16", np.int16, 1)])
/usr/local/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:526: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_quint16 = np.dtype([("quint16", np.uint16, 1)])
/usr/local/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:527: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint32 = np.dtype([("qint32", np.int32, 1)])
/usr/local/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:532: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
np_resource = np.dtype([("resource", np.ubyte, 1)])
/usr/local/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:541: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint8 = np.dtype([("qint8", np.int8, 1)])
/usr/local/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:542: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_quint8 = np.dtype([("quint8", np.uint8, 1)])
/usr/local/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:543: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint16 = np.dtype([("qint16", np.int16, 1)])
/usr/local/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:544: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_quint16 = np.dtype([("quint16", np.uint16, 1)])
/usr/local/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:545: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint32 = np.dtype([("qint32", np.int32, 1)])
/usr/local/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:550: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
np_resource = np.dtype([("resource", np.ubyte, 1)])
Traceback (most recent call last):
File "run.py", line 4, in
from init import select_ticket_info
File "/opt/12306-master/init/select_ticket_info.py", line 16, in
from init.login import GoLogin
File "/opt/12306-master/init/login.py", line 12, in
from inter.GetRandCode import getRandCode
File "/opt/12306-master/inter/GetRandCode.py", line 6, in
from verify.localVerifyCode import Verify
File "/opt/12306-master/verify/localVerifyCode.py", line 14, in
graph = tf.get_default_graph()
AttributeError: module 'tensorflow' has no attribute 'get_default_graph'
[root@localhost 12306-master]#

https://github.com/testerSunshine/12306/issues/458


Fix pika_algorithms_find_package

Make it a macro so that find_package/dependency are scoped correctly.
Apparently CMake cares whether find_package/dependency is called within a function or a macro. The failure case when it's a function is that CUDA will be found by the pika configuration file, but when linking to pika::pika CMake will complain with:
-- Configuring done
CMake Error in testing/testing/CMakeLists.txt:
  No known features for CUDA compiler

  ""

  version .

A manual enable_language(CUDA) in the top-level scope will "fix" this as well, but since it's pika's responsibility to find CUDA, pika_algorithms_find_package should just be a macro so that enable_language(CUDA) is called in the correct scope to start with.
May fix part of #3. Fixes the configuration error here: https://cdash.cscs.ch/build/57573/configure. CI will tell if the build itself is also good.

bors try

bors merge

bors merge


Can not use tab for auto code completion

🤔 Issue

I am trying to press <tab> to get the suggestions of variables, methods etc... but it doesn't appear. The kernel gets busy for 2 seconds but then nothing.
Using: Latest Chrome on Ubuntu 22.04 LTS
🤔 Is it the LSP server?

Taking tooo long to initialize, and still it hasn't been initialized. I installed via pip but still nothing.

Please suggest the fixes.
Thanks.

It solved my issue. The LSP server was included in the "disabled list".


Fix avoid_redundant_argument_values analyzer warnings enabled in the latest Dart SDK

See https://github.com/flutter/flutter/pull/103719

FRoB testing seems to be having some issues. Landing manually to unblock the engine roll.


ProxyCommand doesn't work without prior direct log in via (aws ssm start-session --target i-instance)

Hello.
First I'd like to say thanks for this script it has helped me. Second, I'm aware I may actually be facing some configuration issues on my instance here, but wanted to ask the question in case you can shed light on something.
I wrote a script to generate the .ssh/config using our server names for easier location of the box. This is for easier tab-completion when figuring out which box you want to log in to. The entries look like this:
Host core-api-demo-application-server2
  ProxyCommand bash -c "/Users/jhirn/src/tflow/core_api/bin/aws/ssh_via_ssm.sh i-0..... %r %p ~/.ssh/id_rsa.pub"
  StrictHostKeyChecking no
  IdentityFile ~/.ssh/id_rsa
  User jhirn # or ssm-user, see below

I've added User so I log in as myself and this works just fine. However, we have some users that are not preconfigured on the machines and still need SSH, so I've switched this from jhirn to ssm-user which is the base account used when doing aws ssm start-session. Logging in as jhirn works, but only if I've previous logged into the machine directly with aws ssm start-session --target XXX) at least once. When I do this, I'm logged in as ssm-user. If I log into the machine as myself prior do doing so, I actually get No passwd entry for user 'ssm-user' if I try to sudo su - ssm-user.  That kind of makes sense for why it's not working, but I'm just curious why  AWS-StartSSHSession via command line logs in the ssm-user just fine, but not via ProxyCommand without a prior login. Also curious if there's a way to make the AWS-RunSHellScript script create the user when copying the key so the ProxyCommand script will just work. I could just create the ssm-user but want to make sure it's done in the same way aws ssm start-session would do it.
Happy to provide more details such as ssh -v output. I have a hunch the AWS-RunShellScript to copy the key may be failing, or that it could be enhanced to add the ssm-user if they don't already exist, but a bit stumped atm.
Thanks!

After some digging this came up https://github.com/aws/amazon-ssm-agent/issues/342. It's quite the chicken/egg however as I can't do AWS-StartSSHSession without the key being there via in ProxyCommand. It doesn't appear AWS-RunShellScript is failing but it's possible that it is. In the least I know it's not creating the ssm-user propoerly for start-session to succeed on a first run via ProxyCommand .

@jhirn have you tried https://github.com/qoomon/aws-ssm-ec2-proxy-command/blob/master/ec2-instance-connect/aws-ssm-ec2-proxy-command.sh ?

btw I think the default user is ec2-user

do you really want to create an individual user account on the machine for every user connecting?

Wow thanks for the responses. Really apreciate the fact you've replied multiple times =).
Let me try the ec2-instance-connect send-ssh-public-key flavor of the script. I'm assuming that it would need ssm-user to exist but I'm totally stumped at this point.
I had the though of trying to create the user manually via useradd.  I know the agent also adds that user to sudoers and unsure what else it might need for it to actually be a "true" ssm-user. There doesn't seem to be a way to invoke the agent and simulate a first start-session other than doing aws start-session. Kind of a bummer.
Definitely do not want to need to have an individual user account on each machine, but I already have one for most and we are in the process of completely redoing out infrastructure so this was just supposed to be a stop gap and it's driving me bananas.

So I added the following and it works as expected so far. Hopefully there's not any extra wiring up of the user that I'm leaving out but does what I need in the interim.
useradd -m ${ssh_user}
echo \\\"#User rules for ssm-user\\\" > /etc/sudoers.d/ssm-agent-users
echo \\\"ssm-user ALL=(ALL) NOPASSWD:ALL\\\" >> /etc/sudoers.d/ssm-agent-users

Going to close this. It may help some to find in the issues but I'm not sure it's something you'd want to add to the script. Perhaps a Readme entry wouldn't hurt?