Make new image height crop optional

Is your feature request related to a problem? Please describe.
With PR #5129, v.0.91 changed the way medias are displayed, making some users and artist frustrated.
As a matter of fact:
1/ I also loved having big vertical images that were not cropped and took the full column width. Now nearly all medias got cropped and reduced in height and width for almost no reason, which makes Bluesky less appealing for artists and "gallery" feeds.
2/ I didn't understand the meaning of the new icon popping on nearly all medias until I checked the PR. It would be interesting to check how many users get it.
3/ Now I'm urged to open every media that has the crop icon to check them, which breaks the feed scrolling. Also, most of times it's only a few pixels that have been cropped out, because artists usually don't make 3:4 illustrations. I think most people won't get that the picture has been cropped, though (because of 2).
Describe the solution you'd like
Revert to the old display and make the new crop optional.
Describe alternatives you've considered
Allow aspect ratios up to 9:16 (standard) before cropping. Artists usually make art taller than 3:4 but not taller than a smartphone standard aspect ratio.
Make the old display optional. Most people will have the crop icon popping though and it breaks the nice "art gallery" feeling on Bluesky, especially "picture only" feeds.
Additional context
PR: https://github.com/bluesky-social/social-app/pull/5129
https://main.bsky.dev/profile/kimhu.bsky.social/post/3l3ublhsqsx2w
This one like many others gets cropped for only a few lines:
https://main.bsky.dev/profile/datcravat.bsky.social/post/3l3nmldyixi2n
Keke's baguette post:

I concur. Scrolling through the feeds and being able to see images uncropped without an extra click to expand them was one of the best features of Bluesky. The new ratio messes with this experience, and worst case renders some posts (especially memes with text on top/bottom) unreadable on first glance. If a crop is needed, it should only crop very long images over 9:16 ratio as suggested and/or be an optional function to be turned on in the settings.

I think related to #4336 that I raised re: avoiding images that dominate the timeline - I think it's maybe overcorrected a little now (I think a little crop to fit a ratio limit would be acceptable?) in the new version.
Ideally (for me) something that caps the size, and just scales down to a max? That may affect the overall balance of the app though (i.e. portrait or skinnier images would have a lot of space either side).

I agree with this suggestion. Also cropping images leads to more clicking on the users side.

+1 to kinokonoonnanoko's suggestion, the image should only be cropped by the app view if they are extremely tall

Completely agree with the ask, since quite a few artists seem to be having difficulty adjusting to this new ratio crop. If we can’t have a toggle, perhaps adjusting the proportions might help.

Absolutely agree. I don’t like to have to open so many images just to see them fully and sometimes you can even miss important context due to crop.
Also it’s quite ridiculous to crop just a few pixels because image was barely over the limit.

While I understand the need for some kind of limit to avoid issues that sites like tumblr had with images that would span multiple post-lengths long, where people would purposefully add way too many of them to annoy other users, I feel like it would make the most sense to at the least allow phone-aspect ratio images before being cropped like was previously given as an example, since that's really unlikely to ruin the scrolling experience

16:9 is fairly standard these days for aspect ratios. Portrait oriented pictures in that ratio shouldn't be cropped.

The crop feature was just implemented on my side and I don't get it, most of the times the crop isn't even helping because most people don't make extremely tall pictures either, as described.
+1 for @kinokonoonnanoko for me too, to me their suggestion makes the most sense.

I do think 9:16 can end up way too tall if the width is scaled to the viewport (e.g. a quote of an image post is more than a phone screen tall for a single post) - but some kind of max height constraint could sort that out - scaled to within a specific bounding box. That seems to be the approach taken by threads - that mostly just scales the image (though applies a crop sometimes on weird ratios).

I agree as well; one of the (many) things that made Bluesky better than that other site was being able to see the work artists post without it being terribly cropped.

Agree, this needs to be reverted or at least made optional.

I do think 9:16 can end up way too tall if the width is scaled to the viewport (e.g. a quote of an image post is more than a phone screen tall for a single post) - but some kind of max height constraint could sort that out - scaled to within a specific bounding box. That seems to be the approach taken by threads - that mostly just scales the image (though applies a crop sometimes on weird ratios).

I don't like Threads when it comes to media display, I actually think it's the worst you could do. I guess it's a matter of taste :)
I prefer the media to take the max width instead of being weirdly left aligned with a blank part on the right, even if it ends up bigger than the viewport in my feed. I think that's what happened on Bluesky until the last update, and it never bothered me. It's very different from what X and Threads offer, and closer to what Mastodon and Misskey do. Both have settings related to media cropping btw.

I also prefer that if things are to be cropped it covers the maximum timeline viewport size... I think, personally, a good solution to cropping being unfriendly to artists is to allow manual crop area selection, like old school forum icon uploads. It allows for some sense of intention and framing to remain and prevents cropping out important areas.

Adding an auto-crop annoys me on several levels. As an artist I've observed it making minor, frankly pointless crops to my images that are in very normal formats. I have no control over this which means that composition on bluesky is going to be rubbish unless I adhere to its specific peculiarities. If it has to happen at all it ought to at least be controlled by the uploader.
As a user reading the site it burdens me with having to frequently stop and expand an image like a meme or other similar thing that I had zero need to see up close, because now I know something is missing from it but have no idea what. Mostly it's minor, pointless crops. Other times it's something like a small screenshot which is now missing context until I expand it, but which would have been perfectly legible under the old system.
This is a pointless time waster during normal use of the site. If I could turn it off I'd do it once and never think about it again, just like I never missed this "feature" in the first place.

I agree with this. It was really nice to have the images full width and uncropped. The feed looked a lot more balanced and less chaotic than the like of X and Threads.
Of course there needs to be a limit, but min height should at least be 9:16. If the thought behind this was to save scrolling time, having QRTs be full sized is more of a problem (even though I still like it that way personally).

As an artist, the fixed viewport degrades my ability to communicate my work. As a user, it degrades the usability of the site by  adding friction and extra clicks. This change should be rolled back or at minimum, made an option in setting like auto play gif & video.

modern design dictates (uniform) scale don't crop. this is a blow to artists' marketing, self-promotion and overall display of the artworks / photos that are designed with specific viewing experience in mind that is being hindered by this design choice. now
you cannot easily read webcomics with this. you also cannot capture anyone's attention and present your work in good sense, as even basic grid rules stop applying and attention is being pushed into different, less refined parts.
on the side note, first reply changes, now this, the platform is appearing more and more anti-artists and i don't think this is a good direction to go with.
this is like, experience-breaking change for many artists and art enjoyers.

Thanks for feedback. Can yall drop a few links to specific profiles and/or posts where the new behavior is noticeably worse? It would also help to clarify whether it’s the web behavior or mobile app that’s frustrating (since they use a slightly different algorithm).

Example (web version)
bad crop + scaling + left alignment
I'd say it's equally frustrating than on X.
And I don't think it's a good idea to compare X and Bluesky. IMO it's better for Bluesky to have its own "personality". Scaling and cropping images to constraint the height of all posts kind of killed the "wow" effect it had before. It's important because artists are amongst the hardest kind of people to persuade to make a switch since they have not a lot of time on their hands but have a lot to lose by changing their social networks. The artists I personally know don't like crops because it forces them to export a different version of their pics for every social network they're on.

Examples

Dislike that this is shrunken and shifted off to the left-- the intention perhaps to limit impact of cropping tall images... instead it just hurts the intentional framing AND makes viewing it full size sort of not worth the time. Shifting it off to the side is also unappealing (and on making the window smaller, possibly a bug because it's fine if the window is small enough to make both sidebars disappear). would rather it cut off MORE if it's going to crop.
Then...

vs the full size image...

good example of the crop both hurting the intricate frame of this work as well as just... making it feel kind of silly to have cropped in the first place. it almost feels like spot the difference at times but stand out in this example because it has no bleed.
All of the most obvious examples I've spotted so far have been works for works for print, photos or comics, like above. Most, at least, are easy to predict and design for. I fully believe works made for A5/A4/A3 dimensions should never crop, I believe currently B5/B4/B3 are probably just stubby enough to not get cropped, but they also shouldn't. As pointed out above, the common 3:4 portrait gets cropped, which is a bit wild. 16:9 is probably too long to get away with... but that comic book cover is really suffering, I feel like whatever proportion that cover is -- that's the sort of upper limit for length for me before I start thinking crop is needed. I understand thats crazy subjective though.

Also, just to clarify — is the new behavior worse/different than on twitter, or are you equally frustrated with the behavior on twitter? Thanks.

In agreement with others that Twitter sucked for this also, and their regular adjustments to optimal posting size made it feel like we were regularly aiming at moving goalposts when trying to make infographics/hiring/available for work posts-- those are kind of boring in the first place so if its hard to grasp the info at a glance people tend not to click through at all. I think limitations are okay, they just need to either be somewhat controllable or reliably predictable.

I agree I don't want the cropping of images done automatically, I want to see the whole image so I don't have to click everything.

I am supporting the request to not crop image height on the timeline, as an artist

As I understand it, the purpose of cropping is generally so the average user's main / mixed-source feeds is not overwhelmed by a few posts (e.g. #4336). For me it's also important from a health perspective: the longer individual posts in my feed are, the more often I have to use my thumb to scroll on my phone, which can aggravate RSI.
When scrolling on my phone I'll generally see three or four different text posts (sometimes five!) on the screen at a time. But even with the current cropping rules in version 1.91, the moment one of the posts contains a portrait image I'll see 1.5 posts max on the screen. And if the post is a quote post with an image of a post that also has an image, then I won't even see the entire quote post at once on the screen.
So as a browsing user, I do want automatic cropping of images and a more compact view for quote posts - in my main feed. But if I'm in a view where I expect to primarily see image content, then I don't mind the additional scrolling (and may intentionally be scrolling less because I want to stop and look at the images). The main example here is the Media tab for a user, but the Posts tab for an artist (who might be regularly reposting art from other users in addition to their own) would also be the case, as would an art-specific feed, or an alt account specifically for following artists.
So my question here is, how viable would it be from a UX perspective to have different default crop behaviours in different views? The main downsides I imagine here is predictability on the part of both the user uploading an image and the user browsing a view, but if e.g. there are just two defaults ("compact" and "larger") then that might be manageable. A config option like has been suggested upthread could also allow users to toggle between the two defaults in their main feed.

For me it's also important from a health perspective: the longer individual posts in my feed are, the more often I have to use my thumb to scroll on my phone, which can aggravate RSI.

Maybe an option to be displayed cropped or not should be on the user side and not server or poster side. If some people prefer seeing everything, they'll be annoyed if the auto crop is installed. But for people that prefer when stuff are cropped, seeing everything will be annoyed, so either way you're kinda making mad a part of the user base, unless you offer them the options to see the images as cropped or not?
Because i do get that some people does find annoying (or even painful in certain cases) to scroll a lot just to go past one post... Which is in part what a micro blogging platform is for, seeing the most posts in the view port size of the screen.
Not sure how much harder that would be to implement such kind of option, but it'll defo be more work than just choosing one or the other.

I’d like to reiterate that it’s really important we nail the defaults — adding options doesn’t do anything for the majority of people (either on consuming or producing side) and there would still be a debate about the default. So let’s focus the discussion and examples on the default, not on the toggles.

Thank you for listening to feedback on this and taking it seriously! I'd like to chime in and say that letting the cropping be toggled off on the user side is something I'd like to see, but I also don't feel like that would make a good solution on its own-- because then that's something we have to ask our audiences to do in order to properly view our work. Then you end up with some people who have the crop on, some people who have it off, and you end up having to do the same work anyway because you have to account for the people who are going to see the terrible crop of your images if they haven't changed their settings.
Another BIIIIIIIIGGGGGG problem with this kind of cropping is that you end up cropping out people's signatures partially or fully-- and then people who don't know how to save images on their phones screenshot our art, it loses the signature, maybe they post it somewhere else... it's a whole thing.
Also... I've been on bsky a year now and I have never once had a problem with a too-tall or too-wide image. Rounding the corners on images isn't making the website look better, it's mostly just making everything look a little awkward and out of place, and driving artists bonkers.

This is on desktop. The goal here is... unclear to me at best. This is a tall image with admittedly weird proportions, but it's not so tall or weird that it was impossible to scroll past comfortably, and now it just looks messy. It's not the worst that's ever been done to my art by a website (twitter would have sliced it down to only show her from like, chin to hips or something back when things were at their worst there) but it's bothersome.  And it just took off a fraction of the top of her head.
My app hasn't updated yet, and it looks absolutely fine there:

There's just... no need for this crop to be happening on the vast majority of images, sorry. Since this update rolled out, I haven't seen a single cropped image that actually needed to be cropped. Just a lot of awkward edges on stuff. :(
The best solution, in my opinion, is to figure out where you want to start containing the outliers-- and then, most importantly-- let people choose how their actually-too-tall images are cropped. But leave everyone else's single-image posts alone! Pretty please! Full-width is cool and good! Thank you! (I hope this didn't sound too grouchy lol)

For more feedback, the Mastodon fork I use has a setting for "Letterbox" media which looks like this:

This could be a reasonable compromise and sensible default for allowing the full image to be visible whilst also not allowing images to stretch out feeds. At least, more sensible a default than cropping to focus on a woman's breasts and crotch at any rate.
Of course, long term, I think the best is to have this configurable for the user, and allow uploaders to manage their own cropping.

@gaearon
just as doodlemancy mentioned in  , signatures / watermarks are getting nuked with cropping too

I agree that the crop is too extreme, formats strangely by not filling post field horizontally, and is detrimental to a smooth experience for users. It unnecessarily dings artists whose work and income is often dependent on their social media presence. Echoing that the cut-off should be 9:16.
Examples, mostly of my own posts, but also one recent other one that clearly shows how it negatively affects both user and poster experience.

We'll give 16:9 cutoff a try and see how that feels against examples in this thread, thanks everyone again!

I'm a big fan of the option that RossBrunton shared just a few posts up — scale the image to fit within an embedded viewport, and center the whole image within the post.
One thing Twitter does that I do like, is filling the black space with a scaled & blurred copy of the image. A quick mock-up example:

In addition, I would suggest giving users the ability to set our own preview crops. Let us choose whether the image is scaled to "Fit" or "Fill" the preview viewport. For users who select "Fill", provide an option to override the automatic crop so that we can frame the image manually.
And then finally: Give users an additional setting in Following Feed Preferences, to toggle whether images have smaller previews, or are allowed to be big and expand the post, as a way to side-step these crops/previews.

I'm not sure if this is the issue to say this but I also think videos are being cropped very egregiously on mobile.

https://bsky.app/profile/comiccontext.bsky.social/post/3l3wh2xkt2f2l
Comics Without Context regularly posts tall images, with the punchline now getting cut off. I’d like to see images uncropped at least to 2:1 aspect ratio.

While I understand the need for some kind of limit to avoid issues that sites like tumblr had with images that would span multiple post-lengths long, where people would purposefully add way too many of them to annoy other users, I feel like it would make the most sense to at the least allow phone-aspect ratio images before being cropped like was previously given as an example, since that's really unlikely to ruin the scrolling experience

I would like to add that I think tumblr actually has the best solution for extremely tall posts, specifically added to combat that behaviour.

You can enable the option to shorten long posts, which rather than popping out an image into a lightbox that you then also have to click out of which is frustrating and stops you in your tracks whole scrolling, just shortens the height of the post with a button to expand it. This allows you to easily scroll past long posts that do not catch your attention, and also lets you view long posts inline in your timeline with a single click that doesn't interrupt your scrolling. It's just overall better UX than cropping the image and expanding it in the lightbox.
Before this was a native tumblr experience, i used an extension for the same feature. For me, 150vh was the ideal point for cutting long posts, but tumblr is a longform blogging platform so posts are expected to be longer. I'd maybe say 100vh on bluesky..?

Anyway if we must have cropped images, then I do think at the very least we should be able to choose the focal point of the crop like on mastodon.

Hey y'all, thanks for all this feedback, we hear you! We want to make Bluesky a great place for all types of content, without negatively affecting the experience of users as a whole.
To that end, we've re-tooled the image cropping and aligned on the following rules, which should handle the vast majority of cases pretty well.
Sizing rules:

desktop web

height is limited by a 1:1 square container (see red dashed container in screenshot)
images taller than 1:2 will be cropped (but 9:16, 2:3, 3:4, etc will not)

mobile

height is limited by a 9:16 container (see red dashed container in screenshot)
images taller than 1:2 will be cropped (but 9:16, 2:3, 3:4, etc will not)

Examples

![CleanShot 2024-09-12 at 10 00 38@2x](https://github.com/user-attachments/assets/e55479f3-6900-49b2-ae87-85
b83146f3fe)

There's a huge issue with this new crop when it comes to displaying linked content, the picture pulled from the link is never going to have been optimised to fit BlueSky's layout so you end up with this:

Not a very flattering look for the person pictured!

Hey y'all, thanks for all this feedback, we hear you! We want to make Bluesky a great place for all types of content, without negatively affecting the experience of users as a whole.
To that end, we've re-tooled the image cropping and aligned on the following rules, which should handle the vast majority of cases pretty well.
-snip-

This sounds and looks promising. Still not a huge fan of the left alignment on desktop, but seeing it in context of other posts I'm sort of understanding the decision, and could possibly just acclimatise. Happy to give it a chance given the response time and predictability! Thank y'all 😊

The updates seem to be interesting, thanks for the update. Would it be possible for the site to notify us if a crop happens, before the post is made? Something like "Image too tall; image may be cropped" so that we can adjust the picture.

To that end, we've re-tooled the image cropping and aligned on the following rules, which should handle the vast majority of cases pretty well.

Thank you for the feedback.
Naive question, are the rules based on the viewport's size or is it an app/web fixed rule?
I know it's not the way most people use Bluesky, but I use it on vertical monitor and also use the web version on iPad :)
Else I guess I'd need to wait for a "Better Bluesky" extension 😌

@estrattonbailey
The new sizing rules are great.
But they don't work well in tablets.
Tablets are generally 4:3, 3:2 or 16:10
Examples:
Apple iPad Pro 11 (2024) - 1668 x 2420 pixels, around 3:2 ratio
Samsung Galaxy Tab S9 - 1600 x 2560 pixels, 16:10 ratio
In a 16:10 tablet:

I don't know if link pictures are subject to the same cropping rules but here's a case of an unfortunate crop:


Please feel free to contact me and ask any questions or suggest some features.

如果您对CodeGen存在疑问或着有功能改进方面的建议，请随时与我联系。

When will the new version be released?

The v0.6 has already been released and the v0.7 will be released in next week.


Update authentication documentation

This PR:

Adds documentation surrounding authentication tokens in Reference -> Overview
Adds code samples for each language demonstrating how to set the current auth token

Closes #653

Codecov Report

Merging #826 (07e8132) into main (eda4f39) will decrease coverage by 45.06%.
The diff coverage is 42.35%.

@@              Coverage Diff              @@
##               main     #826       +/-   ##
=============================================
- Coverage     60.24%   15.18%   -45.07%
- Complexity        0      844      +844
=============================================
  Files            14      214      +200
  Lines           483    35382    +34899
  Branches          0     4357     +4357
=============================================
+ Hits            291     5371     +5080
- Misses          192    29335    +29143
- Partials          0      676      +676

Impacted Files
Coverage Δ

go/services/wallet_service.go
0.00% <0.00%> (ø)

...src/main/java/trinsic/services/AccountServiceKt.kt
0.00% <0.00%> (ø)

.../main/java/trinsic/services/CredentialServiceKt.kt
0.00% <0.00%> (ø)

...rc/main/java/trinsic/services/ProviderService.java
50.00% <0.00%> (ø)

...rc/main/java/trinsic/services/ProviderServiceKt.kt
0.00% <0.00%> (ø)

...rc/main/java/trinsic/services/TemplateService.java
70.00% <ø> (ø)

...rc/main/java/trinsic/services/TemplateServiceKt.kt
0.00% <0.00%> (ø)

...src/main/java/trinsic/services/TrinsicServiceKt.kt
0.00% <0.00%> (ø)

...in/java/trinsic/services/TrustRegistryServiceKt.kt
0.00% <0.00%> (ø)

.../src/main/java/trinsic/services/WalletService.java
75.00% <0.00%> (ø)

... and 234 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 c80d30e...07e8132. Read the comment docs.


TypeError: global.shutdown is not a function

[Fixed]
New issue: certificate is expired.

thanks for informing us!
Any screenshots + extra details would be appreciated!

Hello! I fixed it by restarting the replit app thrice. :'>

alright I will close this issue within half a day if nothing more...


Incorrect exception raised when accessing unknown vhost

When I was making a new connection to broker with an unknown vhost, rabbitpy.exceptions.AMQPNotAllowed was raised instead of rabbitpy.exceptions.AMQPInvalidPath.
My broker version is 'RabbitMQ 3.6.1'.

If you can provide a trace of the conversation with either DEBUG logs from rabbitpy or with tcpdump, I can verify that is the case. My guess is that RabbitMQ didn't allow your user to connect to the VHost and it returned AMQPNotAllowed.

You are right. The DEBUG message says access refused. The root cause is that the vhost "testtttt" does not exist. Here's the log:
DEBUG:rabbitpy.base:Connection setting state to 'Opening'
DEBUG:rabbitpy.base:IO setting state to 'Opening'
DEBUG:rabbitpy.events:Waiting for 1 seconds on event: Socket Connected
DEBUG:rabbitpy.io:Connecting to ('<IP_ADDRESS>', 5672)
DEBUG:rabbitpy.base:IO setting state to 'Open'
DEBUG:rabbitpy.io:Socket connected
DEBUG:rabbitpy.io:Returning PollPoller
DEBUG:rabbitpy.connection:Adding channel 0 to io
DEBUG:rabbitpy.base:Channel0 setting state to 'Opening'
DEBUG:rabbitpy.base:Writing frame: ProtocolHeader
DEBUG:rabbitpy.channel0:Received frame: 'Connection.Start'
DEBUG:rabbitpy.channel0:Server information: 'Licensed under the MPL.  See http://www.rabbitmq.com/'
DEBUG:rabbitpy.channel0:Server product: 'RabbitMQ'
DEBUG:rabbitpy.channel0:Server copyright: 'Copyright (C) 2007-2016 Pivotal Software, Inc.'
DEBUG:rabbitpy.channel0:Server supports exchange_exchange_bindings: True
DEBUG:rabbitpy.channel0:Server supports connection.blocked: True
DEBUG:rabbitpy.channel0:Server supports authentication_failure_close: True
DEBUG:rabbitpy.channel0:Server supports direct_reply_to: True
DEBUG:rabbitpy.channel0:Server supports basic.nack: True
DEBUG:rabbitpy.channel0:Server supports per_consumer_qos: True
DEBUG:rabbitpy.channel0:Server supports consumer_priorities: True
DEBUG:rabbitpy.channel0:Server supports consumer_cancel_notify: True
DEBUG:rabbitpy.channel0:Server supports publisher_confirms: True
DEBUG:rabbitpy.channel0:Server cluster_name: 'rabbit@ubuntu1404'
DEBUG:rabbitpy.channel0:Server platform: 'Erlang/OTP'
DEBUG:rabbitpy.channel0:Server version: '3.6.1'
DEBUG:rabbitpy.base:Writing frame: Connection.StartOk
DEBUG:rabbitpy.channel0:Received frame: 'Connection.Tune'
DEBUG:rabbitpy.channel0:Tuning, client: 300
DEBUG:rabbitpy.channel0:Started a heartbeat timer that will fire in 90 sec
DEBUG:rabbitpy.base:Writing frame: Connection.TuneOk
DEBUG:rabbitpy.base:Writing frame: Connection.Open
DEBUG:rabbitpy.channel0:Received frame: 'Connection.Close'
WARNING:rabbitpy.channel0:RabbitMQ closed the connection (530): NOT_ALLOWED - access to vhost 'testtttt' refused for user 'admin'
DEBUG:rabbitpy.base:Channel0 setting state to 'Closed'
DEBUG:rabbitpy.io:Exiting due to closed socket
DEBUG:rabbitpy.io:Exiting IOLoop.run
DEBUG:rabbitpy.io:Exiting IO.run
DEBUG:rabbitpy.base:IO setting state to 'Closing'
DEBUG:rabbitpy.base:IO setting state to 'Closed'
Error: NOT_ALLOWED - access to vhost 'testtttt' refused for user 'admin'

According to the documentation, I was expecting rabbitpy.exceptions.AMQPInvalidPath because there's no vhost called "testtttt".

That error is what's coming back from RabbitMQ -- I'd send an email to the mailing list to see what they have to say on this issue.


State only reports "n_" for Disease

Consider moving State.update_results to Module

Will need to automatically find all States as in _disease_states, but at the Module level.


Instruction for Staking feature on mobile app

Describe the task
Implement Instruction popup for Staking feature on mobile app

[x] Instruction for Staking
[x] Popup warning message lỗi

Link doc: https://www.notion.so/subwallet/Instruction-for-Staking-feature-on-mobile-app-a7674282f4184c69bee53d2f67d5d4e6?pvs=4

Version test: v1.1.14 (252)
Device test: S20 FE 5G
Please check the issues:

[ ] Hide the scroll bar
[ ] The icon incorrect
[ ] Handle case open the app in case pooled

Actual: Open the popup when the user opens Staking tab
Expect: Open the popup when user open the Pooled details screen of the VARA network

[ ] Still shows popup multiple times on the first visit after version upgrade

Version test: PR #1194 19/21/2023
Device test: IP 11
Validation passed in case

Stake, Stake more
Unstake, Unstake all
Withdraw
Claim reward


tensorflow.python.framework.errors_impl.InvalidArgumentError: Cannot convert a Tensor of dtype resource to a NumPy array.

Trying to upgrade the code to use newer versions, I am encountering a blocking issue :
/CloudSimPy/playground/Non_DAG/launch_scripts/main-makespan.py", line 99, in
p.start()
tensorflow.python.framework.errors_impl.InvalidArgumentError: Cannot convert a Tensor of dtype resource to a NumPy array.

Hi AnasHattay,
Same issue here!
Have you been able to solve it?
i guess the problem might be in Agent module bcz only there np.Array can be found! and the reason why the error is in p.start() maybe is that the model is actually running in that phrase.


Redirects to www only matter if they're within the same hostname

This updates the definition of redirects_immediately_to_www to only care about redirects to the corresponding www endpoint.
Previously, that field was set if it redirected to any hostname beginning with www, including external redirects. However, the only reason we would ever care about redirecting to a hostname with www is to evaluate whether the domain appears to be redirecting within itself to favor the www hostname as its canonical endpoint.
The canonical endpoint function was adding an additional scoping around that to make sure it wasn't an external redirect, but that still didn't catch the case where it was redirecting to a www hostname within the same parent domain but not on the same evaluated hostname (e.g. search.cio.gov -> www.cio.gov).
This scopes the redirects_immediately_to_www field calculation, and drops the additional (now unneeded) scoping during canonical endpoint calculation.
There is an interesting tiny edge case where the www endpoint could itself redirect to another www prefix prepended, such as https://www.example.gov -> https://www.www.example.gov. This would set the redirects_immediately_to_www field for the www endpoint. That would be technically correct, and also wouldn't get factored into the calculation of the canonical endpoint for example.gov (which only interrogates the http and https endpoints), so I think that's fine.
Fixes #152.
cc @PaulSD

Nice catch, @konklone and @PaulSD!


Tag trim

Right now this PR passes the uniqueness test in stringArrayEditor, but it should not pass, i need to fix that, somehow.
Added console logs to see what is happening

Could use someone's help in figuring out why trimming where i did it makes it pass the unique tag test.

Can you add more info as to what this PR is trying to solve, and what you mean about not passing the 'uniqueness test'?

The Properties Editor could show "invalid/red input" if there is ever a tag that is a duplicate + trailer space....so with tags test and test , it would turn the input red and prevent adding the second tag. This works by adding the trim() method to the valueIsValid function:

I would vote for this approach. I think validations.js is currently indented solely to detect specific patterns, but not for uniqueness against other values. It makes sense to just update the uniqueness check we already have.

I can go ahead and implement that, and i could add a simple regex pattern to the input, that allows for way easier styling than via js.
input:invalid {
    background:red;
}

In case you've never heard of that, :valid and :invalid are a thing, and work great with the pattern attribute.

i could add a simple regex pattern to the input, that allows for way easier styling than via js.

I think any pattern checking is already handled with valueIsValid() and validators.js. I would prefer we keep any of that logic in one place. I think we even used invalid at the start, but we found that just limiting to regex was not enough, hence the custom solution.

@5e-Cleric I have a full rework of the stringArrayEditor in PR #3469.  I can fold the issue/answer of this draft PR into that one, and close this one--- is that okay with you?

That's fine.

@5e-Cleric I have a full rework of the stringArrayEditor in PR #3469.  I can fold the issue/answer of this draft PR into that one, and close this one--- is that okay with you?

Please do.


Patched the Compara test database to e101 and e102

Description
Updated the test databases to match our e101 schema and advertise version=102
Use case

Our e101+ API expects a certain schema, and raises exceptions if the column can't be found.
Bump up the version number (you guys need to do it as well, following the SOP)

Benefits
Make Travis happy
Possible Drawbacks
None
Testing
Have you added/modified unit tests to test the changes?
Not needed
Have you run the entire test suite and no regression was detected?
Yes

Coverage increased (+0.08%) to 82.337% when pulling 49bc7ca3dc43b42475588f66918911b2dfaaacec on compara_e102_test_dbs into 22fa1e5672b1730d81d4708147be4ecbb64942f2 on master.

Hello. Can you please merge this ? Our Travis is continuously failing because it can't run the Core test-suite, which makes it harder to detect other genuine failures.
Thanks


Code Error

I believe there is an error in the code provided on this screen. When running locally or deploying to Azure with the code as written, I'm getting the following error: "None of [Index(['Segment', 'Country', 'Units Sold', 'Gross Sales', 'Date'], dtype='object')] are in the [columns]"
I believe the line of code that creates the cols list should be:
cols = ['segment', 'country', 'units_sold', 'gross_sales', 'date']
This is because the column names have already been converted to lowercase and had spaces replaced with underscores by the time this variable is used to filter the columns in the processed dataframe.

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

ID: 2d2c9309-2af1-7e36-ecb9-a092224e2355
Version Independent ID: 47dfbb72-e141-486d-a645-2ec8d5c41bbf
Content: Transform relational data with Pandas and Azure Function Apps
Content Source: articles/python/tutorial-deploy-serverless-cloud-etl-04.md
Product: azure-python
GitHub Login: @jess-johnson-msft
Microsoft Alias: jejohn

#self-assign

This article needs to be updated as part of the event release this month.

@adanaher Thank you for this fix. It will be in the next publishing cycle within 24 hours.


Replace Tool by StructuredTool in tool_executor.ts

Because the Tool abstract class extends the StructuredTool abstract class, using a DynamicStructuredTool would not be usable in the ToolExecutor.
https://api.js.langchain.com/classes/langchain_core_tools.StructuredTool.html
Fixes #40
Note: I did not clone the repo locally or tested that.

@bracesproul my bad, I was in the middle of something else, sorry.
I did it the right way this time, hope that it floats this time.


Add strikethrough markdown support

Since it's inlined, the extension is added directly to the core module.

@obask this requires a rebase/cleanup after the latest changes :)

Now that #458 has added inline extensions support, it should be possible to complete the work on this as a separate module

I'm not sure if passing markdownProcessor and extensions as separate args works well. Maybe we should just make extensions public or restructure it in some other way.

Given #600 will likely make inline extensions easier, I'd shelve this until that's done. What do you think?
Maybe we can revisit image loading in the meantime

Given #600 will likely make inline extensions easier, I'd shelve this until that's done. What do you think?

 I don't mind waiting, just didn't want stale comments to hang on this PR.

Maybe we can revisit image loading in the meantime

SG! I can do images on or after Oct 16 if that's ok.

Yes, I have started. It will probably take me a couple weeks-ish to finish tho as I have a busy rest of the month.
Ok for the timing on images. We can also catch up in London.


clean up current home cluster after failover to another cluster is complete

When failing over, DRPC start the failover process and creates a task to cleanup the old primary
in parallel. It is possible that the cleanup task runs before the failover is even started. This
change is to close that window. The cleanup task will only be created when the failover operation
is complete

@BenamarMk Created a backport of the upstream PR #340 to 4.10 (as this can be merged as soon as it passes the GH actions).


Change Type to AdminCenter

Small correction. No spaces are permitted in the Type for an extension so it stood out.
Verified that the Type is AdminCenter based on the New-AzConnectedMachineExtension command in https://learn.microsoft.com/windows-server/manage/windows-admin-center/azure/manage-arc-hybrid-machines#automate-windows-admin-center-deployment-using-powershell.

Learn Build status updates of commit 76cfb53:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/azure-arc/servers/manage-vm-extensions.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#sign-off


Games

[x] Create game class
[x] Create author class
[x] Create UI for list games, list authors, and add game
[x] Preserve data
[x] Add unit test for game and author classes

https://github.com/mikemtzp/Catalog-of-my-things/issues/15
https://github.com/mikemtzp/Catalog-of-my-things/issues/16
https://github.com/mikemtzp/Catalog-of-my-things/issues/17
https://github.com/mikemtzp/Catalog-of-my-things/issues/18
https://github.com/mikemtzp/Catalog-of-my-things/issues/19

Hi @Draxeytina,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.


If handler panic, recover

Today, if the handler in the listener is panicking for whatever reason, message in kafka is not acknowledge and we have a loop on a message triggering a panic.
Proposed solution, recover panic error triggered by handler, and create an error. This way it doesn't break the flow.
What was done:

Code with recover
unit test with panic

Pull Request Test Coverage Report for Build 21

6 of 6 (100.0%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.5%) to 79.87%

Totals

Change from base Build 18:
0.5%

Covered Lines:
123

Relevant Lines:
154

💛  - Coveralls


Data of profile (like version/description) are not visible when profile is being used in OSM contributor

Hello
More an improvement rather than a real issue.
It could be interesting to be able to displayed the version and the description of the profile. These info are set into the yml file.
It is something minor
Thank you in advance

Hi @pdfext, I just noticed that this issue is on the wrong repository.
Please post it on the repository of osm-contributor.

Done


Trigger with Click Events

It would be great if we could trigger confetti automatically when clicks are done to given selectors.
Maybe for the options page, a repeater field that takes a regex for the url, and a css selector.

Hey, that sounds like a nice feature. Feel free to make a PR :)


Dev rename currencies

Added GetExchangeRates procedure and fixed several typos.

Closed in favor https://github.com/slntopp/nocloud/pull/482


Authentication is broken

Somebody changed something, and our unofficial library is dead for now. Sad face emoji.
The authentication code is here: https://github.com/brightway-lca/ecoinvent_interface/blob/main/ecoinvent_interface/core.py

In [3]: release = EcoinventRelease(my_settings)

In [4]: release.list_versions()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[4], line 1
----> 1 release.list_versions()

File ~/.python-virtualenvs/bw/lib/python3.12/site-packages/ecoinvent_interface/core.py:284, in InterfaceBase.list_versions(self)
    283 def list_versions(self) -> list:
--> 284     return [obj["version_name"] for obj in self._get_all_files()]

TypeError: string indices must be integers, not 'str'

the header merging on python 3.12 doesn't seem to work correctly for me at this point:
    @fresh_login
    def _get_all_files(self) -> dict:
        files_url = self.urls["api"] + "files"
        headers = {
            "Authorization": f"Bearer {self.access_token}",
            "ecoinvent-api-client-library": "ecoinvent_interface",
            "ecoinvent-api-client-library-version": __version__,
        }.update(self.custom_headers)

and the token bearer is not passed to the requests call, so I get an "Unauthorized"

Yep, I done goofed. Is this what git blame is for?

https://github.com/brightway-lca/ecoinvent_interface/commit/08d82a82e319e7e67ea602116f8a938d79430ae2#diff-520f88905470cc9f9466f45736fce791dd868cec501af7eb017f28dcb36f171aL130-R130


GET /users/:id

GET /users/:id
Story

As a developer
I want an api that retreives a single user
so that I can get a user's information

Acceptance Criteria

Update the GET /users/:id api do use a mongo collection called 'users'
For the find query object, use {_id: req.params.id}
your response line should be something like res.json(result[0]);
Update your test to only make the following assertion

res.body.should.be.an.Object

Approach

Use the API listed here:

http://mongodb.github.io/node-mongodb-native/2.2/api/Db.html
http://mongodb.github.io/node-mongodb-native/2.2/api/Collection.html

@angkimbrell1 Sprint due TUESDAY 3/28


Patching issue 29

[x] using to_s  method  to returns string representation of an object

[x] using unless l.nil? || l == 0 || (l.is_a? String)  ... end filter string is not null, zero value or not string before ref <<

Submit as patch for #29

@MaximeKjaer Do you have the time to take a quick look?

I got this today, but just adding a note:
> note ""
> No headers in here

And enabling 'premonition' as jekyll plugin in _config.yml

Ran in to this today as well. Any chance we can get this over the finish line, please?

Ran in to this today as well. Any chance we can get this over the finish line, please?

I will do some testing on this tonight.

@iranzo @luispollo I'm having a hard time recreating the problem locally. I have tried with Jekyll 3.8.6, 3.9.0 and 4.2.0.
Hints on Ruby version, Jekyll version and setup would be highly appreciated.

@iranzo @luispollo I'm having a hard time recreating the problem locally. I have tried with Jekyll 3.8.6, 3.9.0 and 4.2.0.
Hints on Ruby version, Jekyll version and setup would be highly appreciated.

root@9ef636a1e4be:/app# gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 3.0.3
  - RUBY VERSION: 2.5.8 (2020-03-31 patchlevel 224) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/local/bundle
  - USER INSTALLATION DIRECTORY: /root/.gem/ruby/2.5.0
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - GIT EXECUTABLE: /usr/bin/git
  - EXECUTABLE DIRECTORY: /usr/local/bundle/bin
  - SPEC CACHE DIRECTORY: /root/.gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /usr/local/etc
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/local/bundle
     - /root/.gem/ruby/2.5.0
     - /usr/local/lib/ruby/gems/2.5.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
     - "install" => "--no-document"
     - "update" => "--no-document"
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /usr/local/bundle/bin
     - /usr/local/sbin
     - /usr/local/bin
     - /usr/sbin
     - /usr/bin
     - /sbin
     - /bin
root@9ef636a1e4be:/app# gem info jekyll

*** LOCAL GEMS ***

jekyll (3.9.0)
    Author: Tom Preston-Werner
    Homepage: https://github.com/jekyll/jekyll
    License: MIT
    Installed at: /usr/local/bundle

    A simple, blog aware, static site generator.

root@9ef636a1e4be:/app# gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 3.0.3
  - RUBY VERSION: 2.5.8 (2020-03-31 patchlevel 224) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/local/bundle
  - USER INSTALLATION DIRECTORY: /root/.gem/ruby/2.5.0
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - GIT EXECUTABLE: /usr/bin/git
  - EXECUTABLE DIRECTORY: /usr/local/bundle/bin
  - SPEC CACHE DIRECTORY: /root/.gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /usr/local/etc
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/local/bundle
     - /root/.gem/ruby/2.5.0
     - /usr/local/lib/ruby/gems/2.5.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
     - "install" => "--no-document"
     - "update" => "--no-document"
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /usr/local/bundle/bin
     - /usr/local/sbin
     - /usr/local/bin
     - /usr/sbin
     - /usr/bin
     - /sbin
     - /bin
root@9ef636a1e4be:/app# gem info jekyll

*** LOCAL GEMS ***

jekyll (3.9.0)
    Author: Tom Preston-Werner
    Homepage: https://github.com/jekyll/jekyll
    License: MIT
    Installed at: /usr/local/bundle

    A simple, blog aware, static site generator.

I've thrown away too much time on this now, so I guess we will just merge it in. I'm not able to recreate this problem with Jekyll 3.9.0. I don't see any harm in merging this in.

I've thrown away too much time on this now, so I guess we will just merge it in. I'm not able to recreate this problem with Jekyll 3.9.0. I don't see any harm in merging this in.

I've thrown away too much time on this now, so I guess we will just merge it in. I'm not able to recreate this problem with Jekyll 3.9.0. I don't see any harm in merging this in.

I've thrown away too much time on this now, so I guess we will just merge it in. I'm not able to recreate this problem with Jekyll 3.9.0. I don't see any harm in merging this in.

@RobbiNespu @luispollo 4.0.1 released

@RobbiNespu @luispollo 4.0.1 released


level 3 pull request not merged yet

@sanjay-kv please review and merge this pull request
https://github.com/Rakesh9100/CalcDiverse/pull/1820
This is the pull request i had created

@sanjay-kv I resolved the conflicts please review and merge when you are free

PR is getting reviewed one by one, you can check the PR before accepting the points request from the contributors @sanjay-kv You can remove the point label from here


Add further sanitization to the Science GCSE form mk2

Context
Paul retested the GCSE form and found that grades in the following format thre errors and were not sanitised: 4/4, 4/3  & 4,4, 4,3
44, 43 also throw a validation error, we should update all numbers including the above to be separated by a dash i.e. 4-4 and 4-3
He also found that the 'You need a science GCSE at grade 4 (C) or above, or equivalent page' rendered whenever you enter a any numbered grade – it should only show if you enter a grade that isn’t a pass grade (this is shown if entering a valid double grade for both English and Maths double award subjects)
Changes proposed in this pull request
Adding another clause that inserts '-' between numerical a double award grade in
the '44' format. This also strips numerical grades of any mistyped non
numeric characters before doing this (I have made an exception in the
case of '%' as this will now just return a validation error.
Also, I found that numerical grades were all being tagged as failures by the
failed_required_gcse? method as the pass grades array had been incorrectly
input.
Guidance to review
Test the above examples in the review app. Are there any loose ends? Also would appreciate thoughts on any other symbols to exclude from the sanitize method.
Link to Trello card
https://trello.com/c/ajbpi20L/3394-double-gcse-grades
Things to check

[x] This code does not rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] API release notes have been updated if necessary
[x] This code does not rely on the addition/removal of Azure config environment variables in the same Pull Request
[x] New environment variables have been added to the Azure config

I've just tested it locally and it's working nicely. Great spot on that other bug 🐛
Can we just add a couple of tests here for the failed_required_gcse? method here please.

Added a few nitty comments, just to make it easier to parse for Regex impaired people like me


add vue 3 support using composition api

... and possibly use TypeScript :)

reference: https://github.com/soal/vue-mapbox/issues/111#issuecomment-662985533

Hello !
Are you making any progress on this side ? I don't see any commit on the refactor/vue-3 branch since november 2020.
Is the library already compatible with Vue 3 ?
Thanks !

@vinayakkulkarni bump on this

My client has a will to contribute few hundreds Euros if there will be crowdfunding on Vue 3 support.

My client has a will to contribute few hundreds Euros if there will be crowdfunding on Vue 3 support.

That is really generous @iBobik, and I really appreciate this but I have been working & have pushed Vue 3 support in v3.x.
You can test it out by cloning this repo and testing it out yourself :)
Closing this as I have to work on the documentation bit so that we can have v3.1.x w/ correct guidance for users using Vue 3/ Nuxt 3


[macOS] Fix heap use-after-free in DisplayServer.

Fix map element used after it's erased on closing window, found by address sanitizer.

Thanks!


update handler to support websocket in the handler.yml

 update handler to support websocket in the handler.yml light-4j master