[$1000] Make emojis larger in other contexts than just single character messages

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

This issue covers several related scenarios:
Scenario 1
Action Performed:
Add an emoji with other plain text characters in a message in the composer.
Expected Result:
The emoji should be larger (19pt) compared to the default size for text (15pt) in the composer. The emoji and text should appear vertically centered with respect to eachother, such that the baseline of the emoji is below the plain text and the middle of the text vertically aligns with the middle of the emoji (like the right-hand-side of this example.
Actual Result:
The emoji is the same size as the rest of the text.
Scenario 2
Action Performed:
Send a message with emoji and text.
Expected Result:
The emoji should be larger (19pt) compared to the default size for text (15pt) in the chat history. The emoji and text should appear vertically centered with respect to eachother, such that the baseline of the emoji is below the plain text and the middle of the text vertically aligns with the middle of the emoji (like the right-hand-side of this example
Actual Result:
The emoji is the same size as the rest of the text.
Scenario 3
Action Performed
Draft a message (of any length) with only emoji.
Expected Result
The emoji should appear very large (27pt) in the composer.
Actual Result
The emoji appear very small (15pt).
Scenario 4
Action Performed
Send a message (of any length) with only emoji.
Expected Result
The emoji should appear very large (27pt) in the report history.
Actual Result
The emoji only appear large in the report history if there is only one emoji in the message.
Scenario 5
Action Performed
Go to Settings -> Profile and add emoji(s) to your last name 😎
Expected Result
The emoji should appear larger (19pt) than the rest of the text (15pt) in the text input. The emoji and text should appear vertically centered with respect to eachother, such that the baseline of the emoji is below the plain text and the middle of the text vertically aligns with the middle of the emoji (like the right-hand-side of this example
Actual Result
The emoji appear the same size as the text.
Scenario 6
Action Performed

Go to Settings -> Profile and add emoji(s) to your last name 😎.
Save your profile.
Open the Settings RHP and look at your name:

Expected Result
The emoji should appear larger (21pt) than the rest of the text (17pt) in the text input. The emoji and text should appear vertically centered with respect to eachother, such that the baseline of the emoji is below the plain text and the middle of the text vertically aligns with the middle of the emoji (like the right-hand-side of this example
Actual Result
The emoji and text have the same height:

Scenario 7
Action Performed

Go to Settings -> Profile and add emoji(s) to your last name 😎.
Save your profile.
Open a chat with another user and send them a message. Take a look at your message in the report history.

Expected Result
The emoji should appear larger (19pt) than the rest of the test (15pt). The emoji and text should appear vertically centered with respect to eachother, such that the baseline of the emoji is below the plain text and the middle of the text vertically aligns with the middle of the emoji (like the right-hand-side of this example
Actual Result
The emoji appears the same size as the rest of the text.

Workaround:
no
Platform:
all
View all open jobs on Upwork

Triggered auto assignment to @Christinadobrzyn (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

@stitesExpensify Do we still want single emojis to be bigger than a emoji in other context (like accompanied by text)? Or we just want to apply the same styling that we apply to single emojis to emojis in all contexts?

If this is a pass. I think it is a good time to minimize the regex used for comparison.

this is the original spec:

The default text size is 15, so when there is text inline with the emoji the emoji will be size 19, and when the emoji is sent by itself it will be size 27.

but I'd like @stitesExpensify to confirm whether we diverged from this plan over the course of design since this feature was on hold for many months.

Thanks @jboniface. If we end up following the original spec I think a good proposal would be

Modify our ReportActionItemFragment of type COMMENT to check if our fragment.text has emojis - but only if it fails our isSingleEmoji test.
If it has, modify our Text to include nested Texts containing emojis with a modified style

Triggered auto assignment to @ctkochan22 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

@jboniface, this Monthly task hasn't been acted upon in 6 weeks; closing.
If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.

Why didn't this get worked on?  @ctkochan22 (or another engineer) can this be worked on by an external contributor? If so, can you add the External label so we can get this posted?
I'm going to reopen for now cuz I think it'd be nice to have multiple-emoji messages show larger

Yeah this can be worked on by an external contributor. I'm not sure why I didn't add the label, my bad.

Triggered auto assignment to @JmillsExpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

Oh I love working on this one. Jumping in now.

Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (Exported)

Triggered auto assignment to @roryabraham (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

I think this issue need to be more specific. I'm really not sure what the requirements are.

Originally I asked @stitesExpensify for specification, but I'm not sure -- maybe we should ask Design? Again, the original spec was:

The default text size is 15, so when there is text inline with the emoji the emoji will be size 19, and when the emoji is sent by itself it will be size 27.

I'm not sure if that's what was implemented, and the values were just too small or what

Super fair feedback. @jboniface do you want to take this back to #design?

@JmillsExpensify posted in slack

Hi, what exactly needs to be fleshed out here? Are we discussing the sizes for emojis in all contexts?

@michelle-thompson yeah, we're trying to clarify what those contexts and sizes should specifically be

If we test the following:
Text - 15pt
Inline emoji - 19pt
Standalone emoji - 27pt
We get something like this, which looks good to me.

The only other suggestion I have is that standalone emojis stay at 27pt, so long as there is no text. Said another way, no max number of emojis before reverting back to 19pt.
Thoughts?

Yeah, I like that. I think the size limiting is kind of arbitrary when the only thing on the line is emoji.

For sure, just wanted to point it out since it seems like only one emoji is currently allowed before reverting to smaller type.

I like @michelle-thompson 's mockup above.  Since there are only two lines with emoji, do you think there are other examples where text/emoji are mixed and matched (on same and different lines) where they might not look clean? or.. look crowded.  ie. the ❤ was under Zany's name and there were a line of only large emoji below that

Here's a few more emojis thrown in for good measure! I think it still holds up pretty well.

Looks good, a few of the emoji look like they're 'raised up' a bit, is that 'to be expected' because of the increased size/ratio of emoji to text?

a few of the emoji look like they're 'raised up' a bit

Agree, maybe we can fix it by standardizing on a line-height of 19pt to match the larger font of the emoji (even for lines that contain no emoji)? Not sure

Yes, since emojis are a different size they're not gonna be aligned perfectly. You can see in Slack the same also happens:

@roryabraham we can certainly try, but I actually don't mind how it looks now! I wouldn't want to increase line height so much that regular text looks oddly spaced out.

Hmmm to my less-trained eyes

Mine too. I think this is achievable via code but the gap between the text lines will be increased.

I think this is achievable via code but the gap between the text lines will increase.

Agreed, but that seems worth it to align emoji better. We could try only increasing the line height for lines that contain emoji, but I would prefer to just increase the line height for all lines because:

Whether or not a line contains an emoji is hard to calculate (esp when the window resizes, etc...). This would be too hard to get right to be worth even trying imo.
We would end up having larger gaps between some lines than others, which would look bad.

Yeah, let's see. May be platform will handle it automatically. Otherwise, I agree with your opinion.

Yeah, I agree that this proposed line height apply to all text, not just lines of text with an emoji. Also, definitely open to seeing how center-aligned emojis will look!

Okay, I took a stab at clarifying the requirements in the OP. Feel free to review, but I feel much better about moving forward with this issue now :)

@JmillsExpensify if the updated OP looks good to you can you please update the Upwork job to match the OP and bump it to $500?

Awesome, great convo! Updated Upwork on both counts.

Approaching a week and still no takers. Given that time preceding our most recent convos, I'm going to raise the price to $1,000 and update the issue title to encourage more contributors to jump in.

It's been a week, so increasing the payout for the issue once more to $2,000

We're on the even of 7 days here, and this would still be great to do, so I'm going to bump once more to $4,000 and then we can decide next week if it's worth going any higher.

@roryabraham I'm curious if you have any theories on why we're still not getting any proposals yet. Is it the difficulty of the issue?

Scenario 4:

Add the following function to EmojiUtils:

function containsOnlyEmojis(message) {
    const match = message.match(CONST.REGEX.EMOJIS);
    return match && match.length === [...message].length;
}

Add this line in ReportActionItemFragment (we will need this variable for the Scenario 2, hence i'm calling it here to avoid calling it twice)

const containsOnlyEmojis = EmojiUtils.containsOnlyEmojis(props.fragment.text);

Replace this line with the

style={[containsOnlyEmojis ? styles.singleEmojiText : undefined]}

Result:

Scenario 2:

Add the following function to EmojiUtils:

function isEmoji(char) {
    return Boolean(char.match(CONST.REGEX.EMOJIS));
}

Add the necessary variables

fontSizeEmoji: 19,
fontSizeEmojiHeight: 21,

And styles

emojiMessageText: {
    fontSize: variables.fontSizeEmoji,
    lineHeight: variables.fontSizeEmojiHeight,
},

In ReportActionItemFragment.js replace this line with

{containsOnlyEmojis
    ? Str.htmlDecode(props.fragment.text)
    : [...Str.htmlDecode(props.fragment.text)].map((char =>
        <Text style={{textAlignVertical: 'center', lineHeight: styles.emojiMessageText.lineHeight, fontSize: EmojiUtils.isEmoji(char) ? styles.emojiMessageText.fontSize : undefined}}>
            {char}
        </Text>
    ))
}

Result:

Scenario 6:

Add the necessary variables

fontSizeEmojiProfile: 21,
fontSizeEmojiProfileHeight: 23,

Add lineHeight to displayName styles

lineHeight: variables.fontSizeEmojiProfileHeight,

Add the renderUserName function to InitialSettingsPage

const renderUserName = (name) => [...name].map((char =>
    <Text style={{textAlignVertical: 'center', fontSize: EmojiUtils.isEmoji(char) ? styles.emojiProfileText.fontSize : undefined}}>
        {char}
    </Text>
));

And call it on this line

? renderUserName(props.myPersonalDetails.displayName)

Result:

Scenario 7:
In ReportActionItemFragment.js replace this line with
{[...Str.htmlDecode(props.fragment.text)].map((char =>
    <Text style={{textAlignVertical: 'center', fontSize: EmojiUtils.isEmoji(char) ? styles.emojiMessageText.fontSize : undefined}}>
        {char}
    </Text>
))}

Result:

As for the scenarios 1, 3 and 5, they require conditional rendering fonts of different sizes inside the TextInput. I don't think this is possible, I've tried researching it and asking my colleagues, but no luck. I'm going to research it a bit more and apdate my proposal in case I find something, but if you have some knowledge about it - I would highly appreciate it if you share. Maybe ther'se an app that has this behaviour (i.e. different font sizes insed the input)?

I will review the proposal in details shortly but starting thoughts are:

As for the scenarios 1, 3 and 5, they require conditional rendering fonts of different sizes inside the TextInput. I don't think this is possible, I've tried researching it and asking my colleagues, but no luck. I'm going to research it a bit more and apdate my proposal in case I find something, but if you have some knowledge about it - I would highly appreciate it if you share. Maybe there's an app that has this behavior (i.e. different font sizes inside the input)?

I agree with this as well. I can't imagine a solution where we can have multiple font sizes on textInput.
But I think we can use multiline TextInput on the Web to render HTML. No idea about the native.

There is no solution proposed for scenarios 1, 3, and 5. And I don't know if that is possible for cross-platform.
@JmillsExpensify Let's discuss these requirements first before I pick the proposal.

Asked here https://expensify.slack.com/archives/C01GTK53T8Q/p1651146286301709

Thanks! Coming back from out-of-office and I just commented on your post.

Based on the discussion in the linked Slack thread in #expensify-open-source, I'm going to close this issue so we can prioritize alternative roadmap priorities. Thank you everyone!

@stitesExpensify I wanted to circle back on this issue now we're prioritizing emojis again. We actually never did anything here and ended up closing the issue with no action. It might be good to resurrect this issue/convo and see if we can/should tackle it with a fresh set of eyes.

Agreed, I think it would be a great addition! Do you think we should re-open this one, or create a new one? I think re-opening this one makes sense considering how detailed the OP is

Nice, agreed. I just re-opened. So next up, are we going to keep this external, such that we're open again for proposals?

Related, I thought it fair to update this issue back to the beginning at this point.

are we going to keep this external, such that we're open again for proposals

Yes, I think that we should start taking proposals again!

Nice, I'll float this one in open-source. It's got Help Wanted on it but it's old so might not be on people's radar.

Hi I am from Callstack and would like to take this and be assigned to this task.

📣 @josemak25 You have been assigned to this job by @pecanoro!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑💻
Keep in mind: Code of Conduct | Contributing 📖

The issue was not linked properly.

Also wow that PR happened very quickly!

@parasharrajat does this issue also handle emoji inside markdown?

I mean when we send a message like this:
italic -> _🥳_
bold -> *🥳*
etc..

Currently, all emoji inside markdown has a small size.

Sorry if I'm confused here, but Emojis should not be affected by markdown. If you were to type *😄* that would not be a single character message

Thanks for the confirmation! So, this won't be an issue then, right?

Correct!

I'm taking over @josemak25 tasks, could you assign me?

📣 @ArekChr You have been assigned to this job by @mountiny!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑💻
Keep in mind: Code of Conduct | Contributing 📖

This issue has not been updated in over 15 days. @JmillsExpensify, @parasharrajat, @ArekChr, @roryabraham eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

@fabioh8010 is working on updating Hermes to support the -d flag in regexes. Most recent updates are here

Latest updates in the linked PR.

I lost track where we're at with this issue? Can someone help clarify?

Hi @JmillsExpensify , in order to continue development we need to implement a new feature in Hermes, which is done and is currently in review. It got another review and I need to do some changes, I'll start addressing today.

Update: Addressed the requested changes on May 14th, waiting for another review at the moment.

Thanks for the updates!

Looks like we're still waiting for another review on the hermes PR.

Update: Asked the reviewer if he had a chance to take a look at the PR.

Update: Addressed more requested changes on the PR, waiting for another review now.

The PR is on hold for now while we're updating Hermes

Update: Still waiting for Meta's team decision about how to merge the Hermes PR.

Still in the pipeline, awaiting https://github.com/facebook/hermes/pull/968 to land in RN 0.73

Milestone: https://github.com/facebook/hermes/pull/968 was merged 2 weeks ago. Still not included in a Hermes release

Still not done.

Same

Whoa, this might actually be the oldest active issue in NewDot, and at long last it's coming off HOLD. Going to dust this off and bring it up in slack...

Confirmed, it's the oldest 😉

Hi! Its Kuba from Callstack team and I would like to take this issue :D

I assigned you @MrRefactor

Thanks @hayata-suenaga !

by the way, I have no idea why I got notification for this issue, but I went ahead and assigned Jakub 🙇

@MrRefactor any estimate on when you'll have a PR ready for review?

@roryabraham  Looking at both issues, Im aiming to create PR mid next week

Still working on the issue, dont have any estimations atm, will try to create PR soon

Looking forward to reviewing!

Hi. I'm Kamil from Callstack - expert contributor group - I would like to take over this task from Kuba

Hi. I'm Kamil from Callstack - expert contributor group - I would like to take over this task from Kuba

I didnt have enough time last week to work on this issue so Kamil is taking this over
@roryabraham

we're discussing reassigning this here

Update:
I was able to make some progress with this ticket and opened wip PR that can be found here.
Issue I'm facing at the moment is that on iOS even though we are extracting emojis (with surrogate pairs) from the string, not every (surrogate pair) emoji is responding to applied styles - for example in iOS screen from the PR we have 2 surrogate pair emojis (😶🌫 and 🇦🇩), if we change value of fontSizeEmojisWithinText to noticeably bigger value, flag emoji will be bigger as expected but size of 😶🌫 emoji stays the same which is not an issue on android and web - both surrogate pairs, both recognized as emojis (red background) but different outcomes.
After this issue is resolved it should be smooth sailing to update remaining places mentioned in ticket description.
Regarding emojis size inside of the composer, I'm figuring out what would be the best and non-hacky way to approach this, I have few ideas in mind and will investigate which one would be best candidate
cc: @roryabraham

Regarding emojis size inside of the composer

Please post in #expensify-open-source and tag @tomekzaw, @thienlnam, and myself

Update:
I've resolved issue that I've mentioned in last update - solutions suggested in previous PRs had problems with flags, skin tone modifiers and some surrogate pairs variations, with updated splitTextWithEmojis we are handling all of that so no emoji variation should be an issue from now on which was our biggest problem.
At the moment I'm solving iOS and Android layout issues where on iOS some emojis are pushed to new line and on Android height of emojis is not considered in emojis-only messages (both issues can be seen in screenshots of WIP PR)
cc: @roryabraham

FYI I've added support for customizing emoji.fontSize in https://github.com/Expensify/react-native-live-markdown/issues/232 but we're waiting for <emoji> tag to re-land in expensify-common/ExpensiMark.

looks like the PR is still WIP.
@kbieganowski any status update?

we're waiting for  tag to re-land in expensify-common/ExpensiMark.

does anyone know where this is being tracked?

@kbieganowski can you clarify if it's possible for you to make progress on this issue before emoji.fontSize is supported in react-native-live-markdown?

@roryabraham - it really depends on what is eta for emoji.fontSize support to land. Status of this ticket (putting aside emojis size in inputs since it is handled by separate PR) is that logic for splitting emojis and text (including all emoji variations) is done, components to display larger emojis in username and comments are updated and working as expected on web and desktop. Right now I'm resolving layout issues on native android and ios for comments with updated emojis. I'm hoping to have it ready for review by the end of week

@kbieganowski emoji.fontSize support in Live Markdown is ready, just waiting for re-landing <emoji> tag in ExpensiMark and we're ready to merge/release

<emoji> tags have been re-added in Expensimark. So it seems like with a good push we should be able to finish this week?

Bumped expensify-common in https://github.com/Expensify/react-native-live-markdown/pull/233.
Finished the PR so that emoji.fontSize style in Live Markdown now works as expected.
Asked @BartoszGrajdek for a quick review.
We should be able to merge on Monday.

Update:
Scenario 1 ✅
Scenario 2 ✅
Scenario 4 ✅
Scenario 7 ✅
Scenarios 3,5 and 7: This is mostly done but at the moment I'm resolving issues on both ios and android where after changing input to RNMarkdownTextInput and passing value prop, on android cursor is jumping to the start after writing 1st character or adding emoji and on ios emoji picker (or pasting emojis) stopped working. After that issue is resolved, last thing to be done is adjusting paddings/height of composer on mobile so larger emojis are centered and not cut from the top.
Note: I had to adjust line height in comments a little bit so enhanced emojis are not overlapping or cut from the top in some cases - this was done for comments both with and without emojis so the UI can stay consistent. The difference is marginal but eliminates issues with taller emojis (I will put that info in PR description and tag someone from design team when it's ready for review).
Scenarios marked as done can be checked in web and desktop recordings in draft PR (I skipped native recordings for now since there are obvious issues described above).
cc: @roryabraham

Update:
Fixed issue of cut emojis when we have emojis only in composer (on native ios and android) as well as some other minor UI issues.
Things left to be done:

After discussion with @tomekzaw and @Skalakid new issue was opened in rn live markdown repo (https://github.com/Expensify/react-native-live-markdown/issues/293). I will bump the version once this is resolved
Scenario 5 - changing current input to RNMarkdownTextInput breaks input styles and functionality, I will investigate this first thing monday. After this 2 things are resolved we should be good for review🤞
Note:
Scenario 6 - I think this AC is no longer valid (text font size for user's name and last name in LHP is set to 22px now)

thanks for pushing this forward!

Scenario 6 - I think this AC is no longer valid (text font size for user's name and last name in LHP is set to 22px now)

Scenario 6 is still valid:

Hello @roryabraham, a bit of an update on this one:
I've updated user's last name input in settings page so emojis are enhanced as well as emoji fontSize in settings LHP (according to your last comment about scenario 6, please note that AC says that emoji fontSize should be enhanced to 21px while current fontSize of this section is 22px so I've changed fontSize for emojis to 25px, let me know if that works for you).
I've opened new draft PR for this ticket https://github.com/Expensify/App/pull/40692 (amount of conflicts in previous PR was not worth wasting the time to resolve them commit by commit)
It seems like there are 2 last things that block us from moving this ticket to internal review:

iOS issue mentioned in previous update (PR to rn live markdown with fix is opened and awaiting review, this will be quick change of version in package.json and that's all)

There is an issue with how comments are rendered in chat (not related to my changes but I would guess this will be most likely blocked by QA team) - there is some kind of race condition while rendering comments that causes emojis regex check to return different outcomes on pretty much each render, change like adding console.log('1234') or some empty loop is causing different render outcome. I've added red bg to emojis within text so it is easier to catch it in for example recording from chrome where 1st comment from the top applies expected styles but emojis in 2nd comment are not styled (I would get different outcome if I would add some random console.log() or loop before render). I've also noticed that sometimes emojis in some comments are styled on 1st render and then not after comments are re-rendered...

Please let me know if we want to create separate ticket for this issue and move this PR forward or investigate the issue in scope of this ticket/PR?

I'm not sure I have a good understanding of the issue you're describing in 2 unfortunately. Can you please report the bug in slack using the template of:
Actions Taken (step-by-step)
Expected Result
Actual Result
then we can discuss what to do once we have a better understanding.

Update:
After long conversation with @fabioh8010 in this PR as well as internal discussions we decided to went with different implementation of text and emojis splitting logic based on solution previously suggested by @roryabraham (with some small tweaks) - it should be bit more performant and easier to work on in the future.
As mentioned by Fabio, there are few other places that were previously using emoji regex with global flag and I'll need to validate if there are no issues after regex changes (and provide small fixes if needed), important note is that after changes to logic and minor UI updates we have same outcomes as before in every place so no progress that was already made is lost.
Another positive outcome of removing global flag from regex is that it most likely caused unexpected behaviours in other places, this change will eliminate that.
I'm leaving this PR as a draft for now since we have 3 ongoing topics:

Validation I mentioned above
RN live markdown PR
Discussion regarding issues with comments rendering in slack

Note: I'll be OoO next week (will be back on May 6th)

Update:
I've applied all the suggestions in draft PR and we are good on that end. 2 issues blocking this ticket at the minute are the things mentioned previously:

Opened PR to RN live markdown
Discussion we started previously here and on slack regarding how comments are rendered - I've investigated this issue a little bit but wasn't able to find the root cause. Please let me know if we want to investigate it more in scope of that ticket/PR or create separate issue so this ticket is no longer blocked

Also, can we add Design badge to issue and PR (I don't have permissions to do so)? - As I mentioned in this comment, line height in the comments was increased a little bit so larger emoji and text in line above it are not overlapping
cc @roryabraham

The Design team will be automatically brought in for a review when you take the PR out of draft since they are code owners of the styles directory.

Discussion we started previously here and on slack regarding how comments are rendered - I've investigated this issue a little bit but wasn't able to find the root cause. Please let me know if we want to investigate it more in scope of that ticket/PR or create separate issue so this ticket is no longer blocked

Let's create a separate GitHub issue for this and not block this issue on it

Hi, I'm Viktoryia from Callstack - expert contributor group - and I would like to take over this issue 🙂

Assigning you to the issue!

Updates:
The PR is waiting for the C+ review

Note: I'll be OOO Jul 1 - Jul 7 🌴

PR merged!!!

The PR got reverted.
I'm going to look through all of the blockers within the app and react-native-live-markdown lib before opening a new PR.

Updates: I have not made much progress here as of today since I was mostly focused on another issue. But I should be able to dive in more starting tomorrow.

Updates: I've started to work on the new PR, created one more issue related to react-native-live-markdown: https://github.com/Expensify/react-native-live-markdown/issues/448

Updates: today I've been focusing on the report screen display - display names and messages.
I'm trying to keep the initial lineHeight, though on ios due to rn issues with emojis alignment within text it's not so easy. That's what I have as for now:

Before
After

It still feels like we aren't quite getting even line spacing though. Do we need to actually make the emojis smaller?
Basically the gaps in the lines here do not look even:

@shawnborton Please, take a look at some options:

fontSize : 15, lineHeight: 20
fontSize : 17, lineHeight: 20
fontSize : 17, lineHeight: 22
fontSize : 19, lineHeight: 22

Sorry if this wasn't clear before, but we definitely do not want to change the line height. We want to keep our standard font line height of 20px here.
So it seems like the only way this works is if we don't actually change the font size of the emojis at all... which might defeat the purpose of this PR, but personally I think it makes the most sense unless we can make it so that larger emojis don't mess up the line height alignment. Any ideas there?

@shawnborton Small note, even on the current main/release, there is inconsistent line spacing on ios:

Also, the emojis are cut off in some places through the app.
I was able to fix it by applying System font size to emojis only:

So at least we can fix issues with current emoji size display.
But I'll do a couple more tries to fit the large emoji as well.

Sounds good, thanks for continuing to dig into this one!

Removed payment from the title since we're still working on this one.

@shawnborton What do you think about increasing emojis font size on ios to 17 and keep the same line height:

Dang, that feels pretty good to me! What do you think? Also cc @Expensify/design for thoughts too.
That feels like the best happy medium we've found so far in terms of making the emoji size slightly bigger but retaining the same line height as the other text.

That feels like the best happy medium we've found so far

Agree—I think this is looking pretty good!

Hmm. Does this mean the font size in chat will be different than everywhere else in the app? 16 vs 17?

Hmm. Does this mean the font size in chat will be different than everywhere else in the app? 16px vs 17px?

@dubielzyk-expensify We change only emojis font size, that's the intention of this issue. The text size is left the same - in most of the cases 15px.

Yup, that sounds right to me. The idea being that emojis should appear slightly larger, otherwise when they are the same font size as the text, they can feel a bit small.

Updates: today I was focused on the web display of the composer and the report screen, that's what I have for now:

Before
After

On the web, the 17 font size for emojis also fits better, especially when it comes to text selection.
TODOs:

implement scenario 5 and 6
recheck all of the reported issues during the first PR merge

Questions:
This issue mentiones increasing emojis size to 27px font size if the message consists of only emojis. But it looks like this already was implemented, with the font size 30px though, should it be changed?

Can you share what the 30px emojis look like? Maybe we can just keep them as-is.

@dubielzyk-expensify We change only emojis font size, that's the intention of this issue. The text size is left the same - in most of the cases 15px.

I see. Thanks for clarifying 😄

Can you share what the 30px emojis look like? Maybe we can just keep them as-is.

@shawnborton That's how it looks right now on prod:

Okay cool, I think the size of that looks fine. But I think we should consider changing the line-height: 35px to something like 20px, so we can make it feel like the composer doesn't shift in size even when the larger emoji is present, like so:

Let me know if that makes sense.

@shawnborton With 20px it has jumping selection line

At this point, 27px font size looks better

Hmm but it sitll looks like the composer is larger/taller than it needs to be. Check my screenshot immediately above and let me know what you think.

@shawnborton Okay, I got what you did and did the same on my side. The composer's height looks okay, but if there are several lines of the emojis, they are overlapped.

But, I've tried to apply increased lineHeight to multiline emojis, and that's how it can look
https://github.com/user-attachments/assets/28b85475-f487-429d-9d81-28b167f717f0

Cool, thanks for exploring that. I feel like we should mimic other apps where if there are more than 3-4 emojis, we go back to the regular text size. I believe Slack does something like this right?

Cool, thanks for exploring that. I feel like we should mimic other apps where if there are more than 3-4 emojis, we go back to the regular text size. I believe Slack does something like this right?

@shawnborton Slack goes back to the regular text size only after 23rd emoji 😄
But I think this is a little bit out of scope, we can add it as a follow-up later.

Hmm but if we add it as a follow up later, that means we're going to run into the emoji overlap issue if we make it so that the composer doesn't need to grow when just a few large emojis are present. So I would prefer to just solve this all at once if we can.

@shawnborton Did you take a look at the video from my comment above? The emojis doesn't increase the composer size when they are in one line and when there are several lines they are not overlapped.

But, I've tried to apply increased lineHeight to multiline emojis, and that's how it can look

https://github.com/user-attachments/assets/28b85475-f487-429d-9d81-28b167f717f0
But if it doesn't work to you I'm okay to update the logic with amount of emojis affecting the emojis size. Let's just mention it under Scenario 3 and 4 in the issue.

Ah okay, well then that would work for me but I'm curious how we would handle textwrapping when there is say 30 emojis in a row on various screen widths?

@shawnborton It looks this way (can't do android, cause dev seems to be down):

Okay nice, I think that can work. What do you think?

Okay nice, I think that can work. What do you think?

For me it looks okay as well. Also, that's doesn't look like super often case (sending the message with 20+ emojis only)

Discussion on-going (Commenting to keep MelvinBot happy).

Updates:

I've implemented scenario 5 and 6
Tomorrow, I'll be OOO (15th Aug), but I think on Friday, I'll start the PR preparing/active testing on all of the platforms.

Updates: I've started to prepare the Draft PR and testing over platforms

Updates:
Continue to work on the Draft PR.
Today, I have tested the WEB platform. I've resolved the remaining TODO related to the correct comment text selection. Only one bug with composer height jumping/increasing when an emoji is entered is left on the WEB. I'll share my suggestions for its solutions tomorrow.

Updates:
I've resolved all of the issues I've found for now and started to combine the PR. I still need to add screenshots and clean the code in several places. If everything goes as expected, I should be able to open the PR for review tomorrow.

The PR has been opened for the review!

The latest updates can be found in the PR.
Note: I'm going to be OOO next week (Sept 16-20) 🌴

FYI Please bump react-native-live-markdown to 0.1.149 to include https://github.com/Expensify/react-native-live-markdown/pull/491 that fixes "Unsupported type: inline-image" error on Android.

Updates: We are waiting for this PR with react-native-live-markdown update to be merged so we can start another round of the review.

Updates: The PR with react-native-live-markdown upgrade was reverted. But the new one has already been opened: https://github.com/Expensify/App/pull/50047, so waiting for it. It's not possible to bumb the lib version outside of that PR cause inline images functionality was added in version 0.1.145.

@francoisl choosing you at random to take this over while I'm on parental leave. Hope you don't mind 🙃

Updates: the PR is waiting for re-review.

PRs in progress

Updates:

Waiting on the confirmation if the last reported bug is truly a bug and should be fixed (see the comment)

Updates:

Resolved conflicts and retested the PR, waiting for another round of review.

Updates:
The PR is waiting for the final review by @francoisl

Payment summary: $1,000 for @parasharrajat via NewDot. Please make sure that you suggest a regression test before requesting payment. Thanks!

Regression test created

Payment summary: $1,000 for @parasharrajat via NewDot.

$1,000 approved for @parasharrajat


support 'export default TestEnvironment'

Summary
Like #7750, but for testEnvironments

Test plan
Added e2e test

Codecov Report

Merging #8163 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master    #8163   +/-   ##
=======================================
  Coverage   62.28%   62.28%
=======================================
  Files         264      265    +1
  Lines       10435    10435
  Branches     2533     2534    +1
=======================================
  Hits         6499     6499
  Misses       3354     3354
  Partials      582      582

Impacted Files
Coverage Δ

packages/jest-runner/src/runTest.ts
2.53% <0%> (ø)
:arrow_up:

packages/jest-core/src/runGlobalHook.ts
0% <0%> (ø)
:arrow_up:

packages/jest-util/src/interopRequireDefault.ts
0% <0%> (ø)

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 d6af3af...28822be. Read the comment docs.


Hello，Excuse me, Why do you want to divide the intrinsic of the eighty-first line of the fuse_depth file by 7.5, Hope to get your reply

Hello，Excuse me, Why do you want to divide the intrinsic of the eighty-first line of the fuse_depth file by 7.5, Hope to get your reply

Thanks for the interest of this repo. This script is designed for rgb-d depth reconstruction by a iPad Pro, where the resolutions of depth and the rgb image are 192256 and 14401920, respectively. To fuse the depth and rgb for the same resolution, the rgb and  the intrinsic matrix are down-scaled by 7.5.


pull request for e2e test at 11/10/2016 00:56:03

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.

Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Setup CI for development and production builds

Using GitHub Actions.

@simskij Do we know what CI Operations are wanted? Test, bundle, etc? Happy to write some github actions to help out

I think that the biggest necessity right now (apart from #4) is building/pushing new Docker images on each release.
Right now this process is manual, and adds a bit of friction.

@KnechtionsCoding that would be great! Yeah, testing, bundling and pushing to ghcr would probably do. I'd be happy to set up any secrets needed (if any, not sure since it's all GH).

@simskij @dgzlopes Is that the make bundle command? I posted #28 when I tried to run it locally to see what the output was.
I'll work on figuring out a GH action for the rest of these in the mean time.

Adding the bundle generation on releases would indeed help users like https://community.k6.io/t/make-deploy-issue-from-controller-gen/5871/. We see some struggles building the operator when following https://k6.io/blog/running-distributed-tests-on-k8s/


Wasm: deferred parsing

Implement deferred parsing for Wasm functions under a flag -on:wasmdeferred
Added new class WasmModuleGenerator which reads only what is necessary to create the wasm module.
Then WasmBytecodeGenerator only generates the bytecode for the function bodies.
Simplified logic for LazyTraps
Added instrumentation for -profile with Wasm
Took the opportunity to do some cleanup in the Wasm classes notably some unused methods and some rearrangement.

This change is

This change is mostly related to https://github.com/WebAssembly/design/pull/719
Regardless of the outcome of that proposal, I think this refactoring will come in handy for the new js api

@MikeHolman @commonlisp Can you review this please?

ping

right now this will have memory cost, so a bit hesitant about merging unless it will be used

:shipit:


Request New Mode Name

Requesting a new mode be implemented to support faucet device types (and potentially other device types):
Name: Warmup
Synonyms: warm up, warmup, warm-up (any alternatives that may be translated from speech)

Would this be similar to the TemperatureSetting trait?

It is different in that it will turn on the device and run until a specific temperature is obtained. This temperature is not part of the invocation, as it is stored elsewhere. The warmup command shall be generic without a degrees supplied.

If you have the OnOff and TemperatureSetting traits, you should be able to do that. You can do relative queries like "make the faucet warmer" to adjust the temperature in a natural way.

We essentially need this as a synonym to preheat. It is used in a similar way. We have a custom action that accepts either syntax and we'd need this Smart Home action to be the same. Therefore, both the syntaxes should be allowed:
Set faucet mode to preheat
Set faucet mode to warmup
This isn't to be used as a means to increase or decrease temperature. It is to obtain a set static temperature. For example, if the preheat temperature is defined to be 90 degrees, the command will turn the faucet on until hardware determines temperature has been met. If this can be obtained with temperature traits, I'll see about using that.

You should be possible to take advantage of the thermostat trait with two modes: off and heat. You could play around with some of the attributes like commandOnlyTemperatureSetting which would indicate that you don't have state data.

If I use the TemperatureSetting trait, that will give me more modes to use. However, I'm still missing the key word(s) we are seeking. Our client has trained the user base to use preheat and warmup interchangible. In today's custom action, phrases like "... to preheat " or "... to warm up " will perform this action. The Smart Home action is initially going to use 'modes' to fulfill this task, until the faucet device type supports a preheat/warmup trait. The TemperatureSetting trait does expose new modes to use, but still fails to bring out the ones the client is seeking. The Modes trait supports 'preheat', but we just need 'warm up/warmup' added (either as a new mode or synonym to preheat).

I think "preheat the device" may map to the OnOff intent for the Oven type (at least for Ovens). Can you try that?

Closing as obsolete.

Closing as obsolete.


Edge: Services pages, Toolbox Icons

on Edge, on the services pages, the leftmost icon in the toolbox for each page is missing.

@Wholloran i tried to reproduce this on the latest changes on dev environment but i'm not able to see this issue anymore, now the three images are displayed correctly. Can you re test this?


Does not work anymore, Could use some work, Needs a 2023 update for more maps...

Sadly by this time im not able to play this beautiful game until my Headset got fixed by itself... So, currently, i cant help you with.
Probably i will try to see what's going on there but rn i cant do much


Display no longer turns on when booting into web configurator after update

Prerequisites
Please check the following before posting an issue / bug report.

[x] I am running the latest version of the firmware found HERE
[x] I have checked the documentation HERE and found no answer
[x] I checked to make sure that this issue has not already been filed HERE
[x] I am reporting the issue to the correct repository

Context
Please provide all relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

Firmware Version: GP2040-CE 0.7.6
Name of device: Haute42 G16
Is this a custom build?: No
Operating System: Guix System GNU/Linux
Browser: Qutebrowser

Expected Behavior
Previously (before updating, 5 minutes ago) if I held start on plug the screen would come on and display some info like the local IP to go to for the web configurator and I believe also said the firmware version.
Current Behavior
I get an orange power LED and am able to pull up the web configurator fine but the little screen is dark now in this mode.
Steps to Reproduce
Please provide detailed steps for reproducing the issue.

Update to latest 0.7.6 stable
Hold start on plugin
Watch the display/lights for activity

I do remember the changelog saying something about having to set up boards again due to breaking changes, but my custom keyboard mode keybinds are still there so it's not like I lost all my settings. I did also go into the display configuration section of the web configurator and it was set to enabled already. Plus it works in other modes.

Hi @Soundtoxin
As per the notes about this release please nuke the device first and then load the firmware on.  This will resolve the issue but you will need to re-do any custom mappings.

Thank you. That indeed fixed it. I used flash_nuke to be safe, but would resetting setting in the web configurator have worked as well for a less extreme solution?

Hi @Soundtoxin ,
I do not believe so as we changed how a number of things work on the back end.


[Bug]: 'Episode' object has no attribute '_autoReload'

Version Number
1.17.0
What branch are you on?
master
Describe the Bug
On one of my libraries, no matter which default overlay I'm trying to add, I end up with the error seen in the included log. It works fine on other libraries.
Relevant Collection/Overlay/Playlist Definition
overlay_path:
  - git: PMM/overlays/audio_codec

Logs
https://gist.github.com/KnifeFed/af48d7e0382cf34aef64827c1110d37e

Turns out it was because I had Seasons set to Hide in the library advanced settings. Setting it to Hide for single-season series works and that serves the same purpose as Hide for me.

Mine is set to hide for single season and I still get this error on shows that have only 1 season.

@rcdailey Does it work if you set it to Show?

Sadly no :(

My YAML:
TV Shows:
  overlay_path:
  - remove_overlays: false
  - git: PMM/overlays/resolution
    template_variables:
      use_1080p: false
      use_720p: false
      use_480p: false
  - git: PMM/overlays/audio_codec
    template_variables:
      Opus: false
      Dolby-Digital: false
      DTS: false
      DTS-ES: false
      Dolby-Digital-Plus: false
      DTS-X: true
      DTS-HD: true
      Dolby-TrueHD: true
      Dolby-Atmos: true

I was running into the same issue, however I have Seasons set as:
Library Level - Show
Single TV Series - Hide
When I change the single TV Series from Hide -> Show - Processing continues as it should with no error.

@rcdailey Do you have any specific shows with Season set to Hide, like @TheSpoon98 mentioned?

I was not aware that you can hide it per show. So I have not explicitly set any that I know of. And it wouldn't be easy to go through each one and check.

I think it should work regardless of that setting, is my point.


Nullability is not respected for form parameters

Observed in: Swashbuckle.AspNetCore 6.4.0
Nullability of (primitive) form parameters is not respected (i.e. misses nullable: true) in the generated schema.
Can reproduce that by using a Controller in ASP.NET Core (6 or 7, doesn't matter), saying
[HttpPost]
public void Test([FromForm] int? nullableInteger, IFormFile file) { }

resulting in
"requestBody": {
  "content": {
    "multipart/form-data": {
      "schema": {
        "type": "object",
        "properties": {
          "nullableInteger": {
            "type": "integer",
            "format": "int32"
          },
          "file": {
            "type": "string",
            "format": "binary"
          }
        }
      }
...

I debugged into the Swashbuckle code to see what's going on, and it seems that for form parameters there is no associated DataProperty, essentially leading to not rendering some metadata properties at all:
isRequired
isNullable
isReadOnly
isWriteOnly

Can't tell if isReadOnly or isWriteOnly would make sense for form parameters, but isRequired and isNullable definitely do. Our use case is a generated C# client (via NSwag), that therefore has a mismatching nullability.
Our workaround currently is an additional IRequestBodyFilter, that sets the nullability of the affected properties manually.

Bumping this up - I observed the same behaviour for query parameters

This should be supported in DotSwashbuckle but you need to enable Nullable in csproj and then set option: c.SupportNonNullableReferenceTypes to true

To make issue tracking a bit less overwhelming for the new maintainers (see #2778), I've created a new tracking issue to roll-up various nullability issues here: #2793.
We'll refer back to this issue from there and include it as part of resolving that issue, but I'm going to close this one to help prune the backlog.


Lack of comprehensive performance evaluation tool

For using OpenWhisk in a latency-sensitive application, I need to measure both latency and throughput of OpenWhisk actions invoked in all modes: synchronously, asynchronously, and (important) via rules. Furthermore, I would like to profile the invocations - separate rule overhead in and action overhead  (in OW) from net action time, but preferably without using Kamino, since I need just quick summary numbers for different deployments.
Currently, there is no tool (or set of tools) in OW that can do that.

closing as #4320 is merged


Fixes #488; allow new line at the end of the line in Safari

Fixes the bug where you could not insert a new line at the end of the line in Safari, when using inline-mode.

My pleasure, glad to have you on the project!


Standardize on && for move, const& for borrow in arguments

Also a StringView etc. should be moved.

See https://github.com/cpetig/wit-bindgen/blob/main/crates/cpp/DESIGN.md for a proposed solution

Solved for strings


Kafqa infinite producer

setting PRODUCER_TOTAL_MESSAGES=-1 will produce infinitely
Refactored the handler method to avoid cyclomatic complexity issue.

Codecov Report

Merging #14 into master will increase coverage by 2.24%.
The diff coverage is 73.52%.

@@            Coverage Diff             @@
##           master      #14      +/-   ##
==========================================
+ Coverage   52.57%   54.82%   +2.24%
==========================================
  Files          15       15
  Lines         504      518      +14
==========================================
+ Hits          265      284      +19
+ Misses        225      220       -5
  Partials       14       14

Impacted Files
Coverage Δ

config/config.go
33.33% <ø> (ø)
:arrow_up:

producer/handler.go
41.37% <41.66%> (+4.34%)
:arrow_up:

producer/producer.go
82% <90.9%> (+8.13%)
:arrow_up:

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 bd60f51...075fb5c. Read the comment docs.


Fixup for tensorrt python wrapper

In addition to Matt Madison patches I have modified the template function getOverload in /python/include/utils.h to accommodate the change in nvidia's tensorrt libraries.

Thanks for the submission.  Does this fix a build issue of some kind?  It would help to know more about what this is for.
Also, if this is a new patch, it would be easier to review if you just added it separately, instead of modifying the original.
Finally, please format the commit message and include a signed-off-by line, as described in our contributing guidelines.
Thanks!

With the old code I got a build error during compiling. After a bit of research I found out that Nvidia recently changed the name of the get_overwrite function to get_overload (compare commit: python/include/utils.h).
At this point it probably makes sense to base this package on the commit mentioned. However, your patchfile is no longer compatible with this version as the layout of the CMakeLists file has changed too (which is why I came up with this messy solution for now 😉)

Hmm.  I'm not sure we can upgrade past the 8.0.1 tag, can we?  TensorRT in JetPack is still at 8.0.1.

Yeah i think youre right. As a kind of hotfix while we are waiting for Tensorrt release 8.2 on Tegra, I reverted the .patch to your original state and stitched in my modifications with a signed-off line commit.

I did some digging on this, since I don't see any issues on master with the existing recipe and patch.
I happened to stumble across a build error trying to build python3-tensorrt on the dunfell branch, however.  The root cause appears to be due to a breaking API change made in pybind11 2.6.  meta-python's dunfell branch provides pybind11 2.4.3 that provides get_overload; version 2.6 and later replaces that with get_override.
  If you could resubmit this PR as an added patch targeting dunfell instead of master, I'll merge it.

Yes this makes sense. I only tested it on dunfell branch and missed up by creating this PR


Strawberry Shake doesn't enumerate errors if return type is Non-nullable

Is there an existing issue for this?

[X] I have searched the existing issues

Product
Strawberry Shake
Describe the bug
When you make a graphQL call to a mutation and there is a validation error of some sort, you would expect to see the validation error in the IOperationResult. However, the graphQL server is returning an empty Data object which gets processed before the Errors object by Strawberry Shake. If the payload is non-nullable, then the empty Data object causes an ArgumentNullException and the error populated in the IOperationResult is "Value cannot be null" instead of the Validation error.
Steps to reproduce

Create an example mutation in the server that always fails with a descriptive error and returns a non-nullable payload
Use strawberry shake to call the mutation and then call EnsureNoErrors() to raise the exception
It will be "Value cannot be null", instead of the descriptive error message.

Relevant log output
No response
Additional Context?
The issue is caused by the code at https://github.com/ChilliCream/graphql-platform/blob/bd3f5559d81c5bdabec152bac10e7da154b6e0d2/src/StrawberryShake/Client/src/Core/OperationResultBuilder.cs#L33. If dataProp is constructed from the Json {}, then the if condition is met and BuildData(dataProp) will result in an ArgumentNullException if the payload should be non-nullable.
To avoid this issue, the code would need to fail the first if condition in order to get the correct error returned. For example, you could add && dataProp.GetRawText() != "{}" and it would skip the first if body. I don't think this is the best solution, but hopefully this helps fully illustrate what the problem is.
Version
13.0.5

Fixed in 13.1.0-rc.0, thanks!

I still have this problem in 13.5.1. In fact it seems worse because it doesn't put the message in the IOperationResult, instead it just throws the exception for me to catch. If I hack the schema to make the payload nullable (by removing the !) then everything works as expected and the validation error shows up in the IOperationResult.


Upload File button in front-end UI, just like OpenAI code interpretor

Inspired by OpenAI code interpreter, I wanna implement my own version, which allow user directly upload some files.
By reading the docs, Chainlit has a AskFileMessage for users to upload files.
However, It's need User input some command text to activate server send AskFileMessage，and it's not quite intuitive.
If it's possible to add a upload file button in front-end UI, and also a @cl.on_file_uploaded_callback decorator. (kind of like Chainlit Actions)

Yes, this is an opened issue. We are open to contributions to speed up the release, otherwise it will probably be added in august.

Sounds great! Can't wait for the new release!

#304


Paddlespeech error: AttributeError: can't set attribute

python-wechaty-plugin-contrib % python paddlespeech-bot.py
2022-07-23 10:23:33,273 - WechatyPuppet.Schema.Base - WARNING - invalid fields: <['endpoint', 'token']> to initialize type<<class 'wechaty_puppet.schemas.puppet.PuppetOptions'>> which are should not be here, we suggest that you should post an issue to python-wechaty to fix this issue
you should give these infos:
* the version of wechaty: 			0.8.63
* the version of wechaty_puppet: 		0.4.21
* the version of wechaty_puppet_service: 	0.8.10
* the token type: <unkonwn> token

/Users/liuhongye/Software/anaconda3/envs/drugdiscovery/lib/python3.7/site-packages/pyee/__init__.py:67: DeprecationWarning: pyee.AsyncIOEventEmitter has been moved to the pyee.asyncio module.
  "pyee.AsyncIOEventEmitter has been moved to the pyee.asyncio "
Traceback (most recent call last):
  File "paddlespeech-bot.py", line 27, in <module>
    asyncio.run(run())
  File "/Users/liuhongye/Software/anaconda3/envs/drugdiscovery/lib/python3.7/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/Users/liuhongye/Software/anaconda3/envs/drugdiscovery/lib/python3.7/asyncio/base_events.py", line 587, in run_until_complete
    return future.result()
  File "paddlespeech-bot.py", line 23, in run
    plugin = PaddleSpeechPlugin()
  File "/Users/liuhongye/UU/wechaty/python-wechaty-plugin-contrib/src/wechaty_plugin_contrib/contrib/paddlespeech_plugin/plugin.py", line 17, in __init__
    self.cache_dir = f'.wechaty/{self.name}'
AttributeError: can't set attribute

You can upgrade the wechaty package to fix this issue.


Upgrade kotlin and idea version to fix kapt issue

Background
https://github.com/square/sqldelight/issues/1336
Previously, the kotlin incremental annotation processing feature is broken once we integrated it with sqldelight.
Change

Upgrade kotlin and idea version, upgrade dependencies.
Build locally and test it with kapt incremental annotation processing feature to verify the fix works

@kpgalligan is tracking the kotlin 1.3.40 change, i think theres a little more involved here which is causing build to fail
other changes lgtm, once kevin gets 1.3.40 in we can merge those as well

@AlecStrong My latest change fixed the build issues. Not sure whether there are other things which need to be taken care of. @kpgalligan mind take a look?

fantastic. looks good to me. @kpgalligan gonna merge this but if theres stuff that was missed please let me know


chore: add a problem from a codeforces contest

Related Issue

Info about the related issue

Closes: #[issue number that will be closed through this PR]
Describe the changes you've made
Give a clear description what modifications you have made
Type of change
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Programming language

[ ] C
[x] C++
[ ] Java
[ ] Python
[ ] Javascript

Screenshots(optional)

Original
Updated

original screenshot
updated screenshot

@prampratap30 could you please raise an issue with problem link and the create a PR
add problem link in the code too
I'm closing this PR for now!


License missing

I suggest MIT, @rkfg are you fine with that? Since you contributed a change to the icon I wanted to ask.

Yeah, no problem, let's go MIT!

done :)


Starting refinery raises KeyError

Describe the bug
Basically I only installed refinery and tried to start it. I got:
>> refinery start
v1.8.0: Pulling from kernai/alfred
Digest: sha256:15fc59b24103ea7e9bebcbf08df1a76fb269778ed54331d320e3f173eaaaf0f1
Status: Image is up to date for kernai/alfred:v1.8.0
docker.io/kernai/alfred:v1.8.0
def7b07916655d70d9b27d3888001b4b611a9cbe0b30f89fade86dc2dc05afe5
Creating docker-compose.yml file...
Traceback (most recent call last):
  File "/program/start.py", line 31, in <module>
    process_docker_compose_template(refinery_dir, minio_endpoint)
  File "/program/util/template_processor.py", line 17, in process_docker_compose_template
    credential_ip = get_credential_ip()
  File "/program/util/docker_helper.py", line 56, in get_credential_ip
    return network.attrs["IPAM"]["Config"][0]["Gateway"]
KeyError: 'Gateway'

To Reproduce
Install kern-refinery==1.3.0 and run refinery start
Desktop (please complete the following information):
Apple M2 Max, macOS 13.3.1

Hi @krlng,
thanks for reaching out. We noticed a similar issue with a different user just recently. There seems to be an issue with the collection of the necessary network address right after the installation (usually because the docker network couldn't be initialized correctly).
The final solution was to restart the computer.
If that doesn't help could you provide the results of the command docker network inspect bridge

Any update @krlng ?

Reopen if the error still occurs


fullscreenEnabled is false for Safari and Chrome on iOS

Following the example app and found that on both Safari & Chrome iOS, fscreen.fullscreenEnabled is always false. The native API responds false as well so I don't think it's this package, any ideas on why this is? I am using a local HTTPS react server

Hey if anyone is still struggling with this issue, I found this thread on StackOverflow. Turns out this is an issue with IOS and other fullscreen libraries like screenful also don't do this check. Try doing this:
try {
    // for most browsers, this will work
    if (isFullscreenEnabled()) {
      fscreen.requestFullscreen(element);
    }

    // for older versions of Safari and IOS, `isFullscreenEnabled` will return false even though it is supported https://stackoverflow.com/a/39083376/10626111
    else if (
      "webkitEnterFullScreen" in element &&
      typeof element.webkitEnterFullScreen === "function"
    ) {
      return element.webkitEnterFullScreen();
    }
} catch (err) {
    console.error("Failed to enter fullscreen:", err);
}


feat(alerts-reports): adding pdf filetype to email and slack reports

SUMMARY

Adding requested pdf filetype to options for alerts and reports
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:
https://www.loom.com/share/accb313d566e413d9ee572a5da86f07c
After:
https://www.loom.com/share/7e52e6e95d094f6192cb84dea3d2a4f9
TESTING INSTRUCTIONS

Create an alert or report a dashboard or chart. Select the pdf option under content format. Save the report and activate it. The report should send as a pdf.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Required feature flags: ALERT_REPORTS=True
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

In which version will this feature be available?

@Shah-Panam This feature will go into the 4.1 release in/around May.

@eschutho Thanks for letting me know.


feat: add support for DBT_TARGET_PATH environment variable

Describe the feature you'd like
It'd be great to have the manifest.json discovered automatically via the DBT_TARGET_PATH environment variable https://docs.getdbt.com/reference/project-configs/target-path#configuration. This seems to relate to https://github.com/dbt-checkpoint/dbt-checkpoint/issues/67 but this environment variable wasn't called out there specifically, so I'm opening a new issue.
Additional context
I am running dbt-core within a Meltano project. I have things working fine with this set of pre-commit hooks (they are great!), but my configuration feels very verbose at the moment due to the fact that my dbt project is located in a subdirectory of the Meltano project, which itself is a subdirectory in my repository.
Here's an example pre-commit config file:
# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.1.0
    hooks:
      # model checks
      - id: check-script-semicolon
        args:
          - --manifest
          - src/.meltano/transformers/dbt/target/manifest.json
          - --
      # script checks
      - id: check-script-has-no-table-name
        args:
          - --manifest
          - src/.meltano/transformers/dbt/target/manifest.json
          - --
      - id: check-script-ref-and-source
        args:
          - --manifest
          - src/.meltano/transformers/dbt/target/manifest.json
          - --
      # source checks
      # macro checks
      # modifiers
      # dbt commands

As you can see, I need to pass the --manifest path explicitly to every hook.
It would be great to have these checks support the DBT_TARGET_PATH environment variable. Ideally, I could set DBT_TARGET_PATH=src/.meltano/transformers/dbt/target in my environment, and the scripts would be able to locate the manifest.json file within that target directory without me needing to set it explicitly on each hook like this.
I'll be happy to try to contribute to this fix if there's support for it.

We have actually discussed this because I have the same problem because we recommend dbt be in a sub directory.
I welcome your contribution. When we spoke about this we thought of including it asa congratulation in .dbt-checkpoint.yaml
an env bar seems good but in datacoves we have a var for the dbt path so ideally we could use that and append /target. Open to suggestions.

In our org we have a similar situation, where our target & manifest are one subdirectory lower than 'standard', in a folder called 'analytics', so our hooks in .pre-commit-config.yaml look like:
  # 1. Models should not have semicolons
  - id: check-script-semicolon
    args: ["--manifest", "analytics/target/manifest.json"]
    files: ^analytics/models/

  # 2. Each dbt model should have a yml schema file
  - id: check-model-has-properties-file
    args: ["--manifest", "analytics/target/manifest.json"]
    files: &models_to_test ^analytics/models/(staging/new|ssot_looker|marts/new_marts|ssot|marts/product)
    exclude: &models_to_exclude (transactions_history|expenses_history|deal_history)   # explicitly ignored disabled models

  # 3. Each dbt model has a description in the yml file
  - id: check-model-has-description
    args: ["--manifest", "analytics/target/manifest.json"]
    files: *models_to_test
    exclude: *models_to_exclude

  # 5. Each dbt model's yml file has a description for each of its constituent fields
  # Note: due to there being so many models with missing column descriptions, this flags a lot of errors.
  # For now, it's only checking the product mart models.
  - id: check-model-columns-have-desc
    args: ["--manifest", "analytics/target/manifest.json"]
    files: ^analytics/models/marts/product
    exclude: *models_to_exclude

We basically have to do the same thing and explicitly define the manifest location each time which seems unnecessary, so I support this idea too! Or if there's a way to set the manifest location once at the top of the config file that could work too.

Closing in favor of #67, the plan is to cover any environment variable.


Unable to run browser example with Chrome 62.0.3202 on MacOS 10.13

Here are my steps:
git clone
alias chrome="/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome"
cd examples
chrome --js-flags="--allow-natives-syntax" browser.html

Is there anything else I should know about? I've tried many variations of flags. The node variant works for me, but not the browser variant. It does enable %GetOptimizationStatus(). %FunctionGetName(), but not %GetV8Version() and %GetOptimizationCount().

GetV8Version is removed from v8

@lauriro - Thanks for the heads up.  I'll remove those from the codebase here.

I've updated the code base and those (and a couple others) have been removed/replaced.


Workaround for loading local files in Android WebView

Based on https://github.com/react-native-community/react-native-webview/issues/656#issuecomment-561067913

Fixes https://github.com/xcarpentier/rn-pdf-reader-js/issues/81

Can you please provide a way to test it correctly?
(ie. place a PDF file in local etc.)


Find/Get the Pull Request description

Hi @peter-evans, I really like this action because how seamlessly it finds comments on other repositories.
Can this be enhanced to get the PR description/body?
If so, I would use your other action (Create or Update Comment) to update the PR description (would require you to update that one as well).
Please :)

Hi @roi-zentner
I would like to keep this action (and create-or-update-comment) focused on comments. I think actions work best when they do one thing and do it well. Adding this functionality would be more than an "enhancement," it would be adding two completely separate code paths because the entities/APIs are completely different.
If you can't find any actions on the marketplace to help you with want you want to do then the next best thing is github-script. That action can help you call the APIs you need on GitHub.

For anyone else who arrives here looking for the same thing: you can get the PR description/body by using ${{ github.event.pull_request.body }} in the GitHub action.


localeChanged memory leak with nuxt SSR

Versions

vee-validate: 2.0.9
vue: 2.5.13
nuxt: 1.4.0

Describe the bug
A 72 byte (If I'm reading this correctly) memory leak caused our server to crash after 3 days
To Reproduce
Steps to reproduce the behavior:

Go to a nuxt project with vee-validate
Click on the start button
Click on the spam button (autocannon -c 100 -d 120 http://localhost:3000)
Watch memory increase some megabytes

Expected behavior
No crashing servers
Demo Link
No demo repo. It's friday at 5pm. If it's needed, I can create one.
Desktop (please complete the following information):

OS: elementary OS juno
Browser: Chrome
Version: 67.0.3396.62 (Official Build) beta (64-bit)

Additional context
AWS memory graph for that server:

Viewing heap snapshots before and after:

Screenshot of Vue instance data:

Maybe this?
::: warning With SSR Frameworks like Nuxt, it is recommended to disable automatic injection since it may cause memory leaks due to all the validator instances being created for every component, which will slow down your site. :::

Injection is disabled.
The file is a little messy. Sorry.
/**
 * artoo/plugins/validation.js
 * Registers vee-validate. We import the minimal build and only import the rules
 * we need. This brings the bundle size down around 50kb.
 *
 * TODO: When vee-validate gets more module, bring this into the component that
 * needs them.
 */

import Vue from 'vue'
import VeeValidate from 'vee-validate'

/**
 * TODO: When PR#1264 gets released we can bring the bundle size down about
 * 50kb.
 *
 * https://github.com/baianat/vee-validate/pull/1264/files
 *
import VeeValidate from 'vee-validate/dist/vee-validate.minimal.esm.js'

import {
  credit_card,
  max_value,
  max,
  min_value,
  min,
  required
} from 'vee-validate/dist/rules.esm.js'

VeeValidate.Validator.extend(credit_card)
VeeValidate.Validator.extend(max_value)
VeeValidate.Validator.extend(max)
VeeValidate.Validator.extend(min_value)
VeeValidate.Validator.extend(min)
VeeValidate.Validator.extend(required)
*/

Vue.use(VeeValidate, {
  inject: false,
})

It should remove the added listeners when the vm is being destroyed. Will investigate and report back


apple: redesign share file sheet

fixes https://github.com/lockbook/lockbook/issues/3129
This PR also adds extra margin for errors in other sheets and makes the folder icons blue in the select folder sheet.
Screenshots
iOS:

iPadOS:

macOS:

I should add the file name and the parent path so the user knows what file they are sharing.


make a GitHub org and keep all our forks there

at https://github.com/scala/community-builds/pull/320 @adriaanm writes:

It was kind of nice to have a top-level overview of which community projects we had to fork, but maybe we can actually do even better in the new format by having a naming convention for the branches that constitute these forks, or by creating a github user that has the forked repos for the community build, so we have a centralized spot to track our forks.

acting as multiple GitHub users is too annoying IMO, but a new org would work

current forks:
    uri:    "https://github.com/adriaanm/sbinary.git#community-build"
    uri: "https://github.com/SethTisue/scalatest.git#3.0.x-community-build"
    uri: "https://github.com/SethTisue/sbt-testng-interface.git#no-bintray"
    uri:    "https://github.com/SethTisue/browse.git#topic/2.12-compat"
    uri: "http://github.com/SethTisue/fastparse.git#no-coursier"
    uri:    "http://github.com/SethTisue/cats.git#community-build-2.12"
    uri: "https://github.com/SethTisue/parboiled.git#community-build-2.12"
    uri:    "http://github.com/SethTisue/migration-manager.git#2.12-compat"
    uri: "https://github.com/SethTisue/spire.git#community-build-2.12"
    uri: "https://github.com/SethTisue/breeze.git#community-build-2.12"
    uri: "https://github.com/SethTisue/specs2.git#community-build-2.12"
    uri: "https://github.com/SethTisue/ssl-config.git#be-dbuild-friendly"
    uri:    "https://github.com/SethTisue/scalamock.git#community-build-2.12"

2.11 still has tons of forks, but we could shrug and figure so what, the action's on 2.12

sbinary is moribund in terms of sbt 1.0

lately we froze some projects because they added wartremover which confuses dbuild

Given that wartremover is a linter, wouldn't it be better to patch the projects to disable it rather than freeze them? Also, are the upstream projects aware of the issue with wartremover and the freezing?

the GitHub org now exists: https://github.com/scalacommunitybuild
I will migrate forks there, time permitting. (I don't have time right now to tackle it all at once, but at minimum we can make our new forks there.)

all the forks are now on the new org
to do before closing this ticket:

[ ] document the new org
[ ] do something with the forks list above? (make a new ticket?)


Fix rendering of indented list for Github flavoured markdown

Just a small documentation change to fix the rendering of the markdown file on Github.

LGTM

Needs a signed-off-by.

Added the signed-off-by line, hope that's correct.

LGTM


Add syntax highlighting for definition lists

This PR was prompted by @ericscheid on gitter:

How easy would it be to add some styling to the brew code for definition-term:: definition?
I'm thinking maybe two tones of colour?

Result:

Editor HTML structure:

	Lorem
	::
	 Veniam incididunt veniam eu. Ad in qui nisi reprehenderit do mollit tempor. Culpa et anim deserunt eu sint nisi qui. Tempor in proident excepteur nisi dolore adipisicing nostrud consequat irure aute culpa. Nulla velit sint deserunt excepteur esse.

Looks good! Thanks @Gazook89

This didn't account for many colons in one line (such as for vertical spacing syntax):

I will try to fix and submit a new PR very soon.

Just for completeness sake, I want to note that this doesn't seem to be a problem anymore.

This didn't account for many colons in one line (such as for vertical spacing syntax):

This didn't account for many colons in one line (such as for vertical spacing syntax):

Just for completeness sake, I want to note that this doesn't seem to be a problem anymore.

Reloaded the page in case of code changes .. still a problem:


Docker / HomeAssistant / NodeRed integration

It will be nice to have a docker image so i can add it on my raspberry pi.
Im not so good on nodejs, but i dont think it will be hard...
On node-red, i dont know the process for creating an addon (palette) but it use nodejs.
Creating Home Assistant Plugin
Creating node-red plugin
Hope to see your project on my favorite platform :)

See my response to Issue #19 for how to get it running on a Raspberry PI (Runs fine on my Raspi).
And see Issue #21 for supporting MQTT. It's easy to integrate with Node-RED, then. Already works on my Raspi, but I still have some issues to fix before creating the pull request. And I've created a new UI that looks a bit fresher:

Seems like @AShifter doesn't have the time to merge my pull requests. Find it here:
https://github.com/michaelewers/harmony-span/tree/issue/%2321
It supports an improved UI and sending MQTT-messages on top of calling webhooks.
This makes the integration with nodered much easier.

Merged. Thank you again!

Seems like @AShifter doesn't have the time to merge my pull request. Find it here:
https://github.com/michaelewers/harmony-span/tree/issue/%2321
It supports an improved UI and sending MQTT-messages on top of calling webhooks.
This makes the integration with nodered much easier.

@michaelewers Andrew says he has merged this, but I do not see the new code anywhere?  The binaries are still from July?

I'm not sure of the proper protocol for this. Hopefully I'm not way off base. I created a docker container from your project. It may not be done 100% correctly though. It does work and I'm running it now myself. I'm pretty sure right now it's restricted to running on port 8060 as that's what your express server is configured to run on. I plan on researching that this weekend but any input is welcome.

I'm not sure of the proper protocol for this. Hopefully I'm not way off base. I created a docker container from your project. It may not be done 100% correctly though. It does work and I'm running it now myself. I'm pretty sure right now it's restricted to running on port 8060 as that's what your express server is configured to run on. I plan on researching that this weekend but any input is welcome.


Update generated model to include roles.

Proposed Changes
Update tests to include testing roles everywhere and the latest service results.

MErged


[PE-D][Tester B] User guide could be more concise

Can mention that the name is case insensitive and extra spaces in between words will be ignored. This is a bit lengthy to read.

Labels: severity.Low type.DocumentationBug
original: JoanneHing/ped#12

parameters table!


Retrieve the accessKeyID from cert-manager-dns-credentials

cert-manager-dns-credentials is already created with both accesskey
secret and access key ID. Let's reuse it from there.

I meant just to please comment out that patch, since it's not needed
anymore.


Add Stride for Collection

Many thanks to @timvermeulen for continued help!
Stride
A type that steps over a collection’s elements by the specified amount.
This is available through the striding(by:) method on any Collection.
(0...10).striding(by: 2) // == [0, 2, 4, 6, 8, 10]

If the stride is larger than the collection count, the resulting wrapper only contains the
first element.
The stride amount must be a positive value.
Detailed Design
The striding(by:) method is declared as a Collection extension, and returns a
Stride type:
extension Collection {
  public func striding(by step: Int) -> Stride<Self>
}

A custom Index type is defined so that it's not possible to get confused when trying
to access an index of the stride collection.
[0, 1, 2, 3, 4].striding(by: 2)[1] // == 1
[0, 1, 2, 3, 4].striding(by: 2).map { $0 }[1] // == 2

A careful thought was given to the composition of these strides by giving a custom
implementation to index(_:offsetBy:limitedBy) which multiplies the offset by the
stride amount.
base.index(i.base, offsetBy: distance * stride, limitedBy: base.endIndex)

The following two lines of code are equivalent, including performance:
(0...10).striding(by: 6)
(0...10).striding(by: 2).stride(by: 3)

Complexity
The call to striding(by: k) is always O(1) and access to the next value in the stride
is O(1) if the collection conforms to RandomAccessCollection, otherwise O(k).
Comparison with other languages
rust has Strided available in a crate.
c++ has std::slice::stride
The semantics of striding described in this documentation are equivalent.

Checklist

[x] I've added at least one test that validates that my change is working, if appropriate
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary

I've rebased against the latest main and included some test cases using the new validateIndexTraversals TestUtilities API. Before merging, it would be good to hear your thoughts on the points that xwu raised here

Stride probably shouldn't require that Base: Collection, but instead implement only Sequence when Base: Sequence.

@timvermeulen

Stride probably shouldn't require that Base: Collection, but instead implement only Sequence when Base: Sequence.

For this, are you implying the following:
public struct Stride<Base: Sequence>

extension Stride: Sequence {
  public struct Iterator: IteratorProtocol {
    var iterator: Base.Iterator
    let stride: Int
    public mutating func next() -> Base.Element? {
      defer {
        for _ in 0..<stride-1 where iterator.next() != nil {}
      }
      return iterator.next()
    }
  }

  public func makeIterator() -> Stride<Base>.Iterator {
    Iterator(iterator: base.makeIterator(), stride: stride)
  }
}

And that conformance to Collection is only applicable when the base collection is also Collection?
extension Stride: Collection where Base: Collection

@natecook1000 Is there any more work required on this for it to be merged?

Thanks, @ollieatkinson — this is ready to go!


Publish as beta release and make repo public

Make sure every package.json is correct and specifies correct homepage etc.
rel: #29

This should be done once #52 and #53 are completed

Closing in favor of our current release process


Notification registration

The API should have a notification registration, where the app passes a lambda that takes one parameter: the notification.  The comments should say that this might throw a UnsupportedOperationException if the library implemented some other form of message passing.

Looks good.


refactor: added static data module for world-v2

https://ccpgames.atlassian.net/browse/EF-4665

@ledablack Since our repository is open source, it's best practice to avoid including JIRA or Confluence links. Instead, please provide a brief description in the PR.


Generate all valid parentheses - Java

Added the code for issue #732 in Java. kindly review it @shreyanspoddar @raksha009

Done @raksha009 :))


Issue Resolved #15 : Color Syle issues with H1

Resolved #15 By applying box-shadow effect into it, to make it standout from the background.

Before:

After

Consider it merging, will be happy to contribute more into this project.
Thanks:)

Really appreciate your efforts, keep it up 👍🏼. Will definitely merge it

@Ctoic Thanks for merging!

Thanks for your time and Happy coding 😄


Wiki documentation updates to cover new Air Purifier accessory type

As requested on PR #139, attached is a diff for the wiki repository containing the proposed documentation updates. I have tried to follow the existing documentation layout as much as possible.
If there is anything else you think needs added let me know.
airpurifier.patch.txt

PR #139 Merged

If I’m not mistaken, you’ve provided wiki updates correct? We’ve got this ready for an upcoming update.
Let me know if I’ve misunderstood your comment


pkgs.python310Packages.ifcopenshell: Out-of-date 210410 -> Latest Version.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/ifcopenshell/default.nix
I privately maintain the latest version of the build, but as it has recently been updated to python 310, in nixos, even if the build succeeds, python loading fails.

https://github.com/IfcOpenShell/IfcOpenShell/issues/2347
import error log.

From a few days ago, in the latest version of ifcopenshell
Another new error occurred.
Now, maybe it needs the lib and bin folders under the global path(nix store) python installed,
error: builder for '/nix/store/65qhxngq2wjzwwpy87q0b8qsx6sizk0f-python3.10-ifcopenshell-master.drv' failed with exit code 2;
last 10 log lines:
> -- Installing: /nix/store/9h9jln7v9x5cbiakja9imgs9vgmp26c2-python3.10-ifcopenshell-master/include/serializers/schema_dependent/XmlSerializer.cpp
> CMake Error at ifcwrap/cmake_install.cmake:49 (file):
>   file cannot create directory:
>   /nix/store/c4i6xn02gfljkh7n84f0qm2nbk3a5bd7-python3-3.10.6/lib/python3.10/site-packages/ifcopenshell.
>   Maybe need administrative privileges.
> Call Stack (most recent call first):
>   cmake_install.cmake:574 (include)
>
>
> make: *** [Makefile:120: install] Error 1
For full logs, run 'nix log /nix/store/65qhxngq2wjzwwpy87q0b8qsx6sizk0f-python3.10-ifcopenshell-master.drv'.
error: 1 dependencies of derivation '/nix/store/4v61z1k87yflv7x014vqn6hi54knnh84-python3-3.10.6-env.drv' failed to build
error: 1 dependencies of derivation '/nix/store/drry2q44vpgm2gippci3agshx74prf6i-system-applications.drv' failed to build
error: 1 dependencies of derivation '/nix/store/34bc7879naqmpbq3v9n51siq6zmjflw9-darwin-system-22.11.20220901.b57e495+darwin4.80cec51.drv' failed to build

Again, it builds & use fine on Nix-Darwin.
NixOS is, as the first mentioned problem,
I'm not sure how import (use) works since it's built... but building now anyway.
I posted the latest code below, can anyone test it and change nixpkgs to make it work on NixOS as well?
On nixos,
This error occurs as a result of importing the latest version of the Python module.

$ python
Python 3.10.6 (main, Aug  1 2022, 20:38:21) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import ifcopenshell

Traceback (most recent call last):
File "/nix/store/qfn7q2m9zp2b1la796qhmgbmkvczi120-python3-3.10.6-env/lib/python3.10/site-packages/ifcopenshell/ifcopenshell_wrapper.py", line 14, in swig_import_helper
return importlib.import_module(mname)
File "/nix/store/c1vb2z3c64i0sd92iz7fv0lb720qcvhb-python3-3.10.6/lib/python3.10/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 674, in _load_unlocked
File "", line 571, in module_from_spec
File "", line 1176, in create_module
File "", line 241, in _call_with_frames_removed
ImportError: libTKernel.so.7: cannot open shared object file: No such file or directory
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/nix/store/qfn7q2m9zp2b1la796qhmgbmkvczi120-python3-3.10.6-env/lib/python3.10/site-packages/ifcopenshell/init.py", line 54, in
from . import ifcopenshell_wrapper
File "/nix/store/qfn7q2m9zp2b1la796qhmgbmkvczi120-python3-3.10.6-env/lib/python3.10/site-packages/ifcopenshell/ifcopenshell_wrapper.py", line 17, in
_ifcopenshell_wrapper = swig_import_helper()
File "/nix/store/qfn7q2m9zp2b1la796qhmgbmkvczi120-python3-3.10.6-env/lib/python3.10/site-packages/ifcopenshell/ifcopenshell_wrapper.py", line 16, in swig_import_helper
return importlib.import_module('_ifcopenshell_wrapper')
File "/nix/store/c1vb2z3c64i0sd92iz7fv0lb720qcvhb-python3-3.10.6/lib/python3.10/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_ifcopenshell_wrapper'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/nix/store/qfn7q2m9zp2b1la796qhmgbmkvczi120-python3-3.10.6-env/lib/python3.10/site-packages/ifcopenshell/init.py", line 62, in
raise ImportError("IfcOpenShell not built for '%s'" % python_distribution)
ImportError: IfcOpenShell not built for 'linux/64bit/python3.10'
@xaverdh  @SuperSandro2000  @Mindavi  @Profpatsch  @ju1m  @alyssais  @wamserma  @fehnomenal
Help me. Sorry & Thanks.
my nix code:
IFCOPENSHELL = let
cgal = stdenv.mkDerivation rec {
pname = "cgal";
version = "master";
src = inputs.cgal;
buildInputs = [ boost gmp mpfr ];
nativeBuildInputs = [ cmake ];
doCheck = false;
};
in with python310Packages;
if stdenv.isDarwin then (
buildPythonPackage rec {
pname = "ifcopenshell";
format = "other";
version = "master";
src = inputs.ifcopenshell;
# version = if stdenv.isDarwin then "master" else "220817";
# src = if stdenv.isDarwin then inputs.ifcopenshell else fetchFromGitHub {
  #   owner  = "IfcOpenShell";
  #   repo   = "IfcOpenShell";
  #   fetchSubmodules = true;
  #   rev    = "blenderbim-${version}";
  #   sha256 = "sha256-051c7igcrlmsQjgJt8a/ZszZolrkZOooItT8qMpyqyE="; # 220817
  # };
  doCheck = false;
  buildInputs = [
    cmake libiconv swig libaec mpfr icu pcre libxml2 boost174 cgal ftgl gcc python310
  ] ++ (if stdenv.isDarwin then [] else [
    stdenv.cc.cc.lib
    cython numpy python-dateutil pytz
  ]);
  propagatedBuildInputs = buildInputs;
  nativeBuildInputs = buildInputs;
  enableParallelBuilding = true;
  dontUsePytestXdist = true; # don't max out build cores, it breaks tests
  preConfigure = ''
    cd cmake
  '';
    # mkdir -pv $out/bin
    # mkdir -pv $out/lib/python3.10/site-packages/ifcopenshell
    # mkdir -pv $out/${python310.sitePackages}/ifcopenshell
  PYTHONUSERBASE=".";
  cmakeFlags = [
    "-DOPENCOLLADA_INCLUDE_DIR=${opencollada}/include/opencollada"
    "-DOPENCOLLADA_LIBRARY_DIR=${opencollada}/lib/opencollada"
    # -DPCRE_LIBRARY_DIR=/usr/lib/x86_64-linux-gnu/
    "-DCGAL_INCLUDE_DIR=${lib.getDev cgal}/include"
    "-DGMP_LIBRARY_DIR=${gmp}/lib"
    "-DMPFR_LIBRARY_DIR=${mpfr}/lib"
    "-DGMP_INCLUDE_DIR=${gmp.dev}/include"
    "-DHDF5_SUPPORT=OFF"

    "-DUSERSPACE_PYTHON_PREFIX=ON"
    "-DOCC_INCLUDE_DIR=${opencascade-occt}/include/opencascade"
    "-DOCC_LIBRARY_DIR=${opencascade-occt}/lib"
    # "-DCOLLADA_SUPPORT=0"
    "-DSWIG_EXECUTABLE=${swig}/bin/swig"
    "-DLIBXML2_INCLUDE_DIR=${libxml2.dev}/include/libxml2"
    "-DLIBXML2_LIBRARIES=${libxml2.out}/lib/libxml2${stdenv.hostPlatform.extensions.sharedLibrary}"
    # ---------------------
    # "-DCGAL_INCLUDE_DIR=${if stdenv.isDarwin then lib.getDev CGAL else lib.getDev cgal}/include"
    "-DBoost_INCLUDE_DIR=${lib.getDev boost174}/include"
    "-DBoost_LIBRARY_DIR=${lib.getDev boost174}/lib"
  ];
  # postInstall = ''
  # '';

};

All of the above builds worked fine.
I switched to Pypi.
In wsl(nixos) and nix-darwin, even without changing the directory, it was imported well.
However, to import on NixOS linux,
You have to move to /nix/store/blahblah-system-path/lib/python3.10/site-packages or the built ifcopenshell-python nix-store directory to import it.
I don't know why, but the day will come when nixos will solve it? thank you
            ifcopenshell-python = with python310Packages; buildPythonPackage rec {
              pname = "ifcopenshell-python";
              version = "0.7.0-220912";
              format = "wheel";
              disabled = pythonOlder "3.9";
              src = fetchPypi ({
                pname = "ifcopenshell_python";
                inherit version format;
                dist = "py310";
                python = "py310";
              } // (if stdenv.isDarwin then {
                platform = "macosx_10_15_x86_64";
                sha256 = "sha256-JTaZtWtn5B3OSgZ+8tZjqhSK/3MNDY8uTkKQivqW0J8=";
              } else {
                platform = "manylinux1_x86_64";
                sha256 = "sha256-PORLVjZXDa4JsCUaGQmMC4DtcuW1t3ZMCiHFg+3g92w=";
              }));
              nativeBuildInputs = if stdenv.isDarwin then [] else [
                pam gcc wrapGAppsHook
                stdenv.cc.cc.lib autoPatchelfHook glibc
              ];
              buildInputs = nativeBuildInputs;
              pythonImportsCheck = [ "ifcopenshell" ];
            };

Somehow I totally missed this, but I'm also afraid I cannot really help you further with this :(

ifcopenshell = with pkgs; with pkgs.python3Packages; buildPythonPackage rec {
  pname = "ifcopenshell";
  version = "0.7.0-221014";
  format = "wheel";
  disabled = pythonOlder "3.9";
  # src = inputs.ifcopenshell;
  src = fetchPypi ({
    pname = "ifcopenshell";
    inherit version format;
    dist = "py310";
    python = "py310";
  } // (if stdenv.isDarwin then {
    platform = "macosx_10_15_x86_64";
    sha256 = "sha256-bsWXS2Y9+e8572q8KClNOKTKljZqq+ugj8uSFld8IlA=";
  } else {
    platform = "manylinux1_x86_64";
    sha256 = "sha256-01S8HCULx58l9JdBLrVUaRgbEkbj9MfQ4dp11KUX8YM=";
  }));
  nativeBuildInputs = if stdenv.isDarwin then [] else [
    pam gcc wrapGAppsHook
    stdenv.cc.cc.lib autoPatchelfHook glibc
  ];
  buildInputs = nativeBuildInputs;
  pythonImportsCheck = [ "ifcopenshell" ];
};

Some credible sources...
I would like to change it to flake inputs.

updated in https://github.com/NixOS/nixpkgs/commit/b9f2aa31ae111f656cea317717a9ffe4b4b5d313


Add reporter for Model::preventSilentlyDiscardingAttributes()

Based on the work of @stayallive made in #824 I added a reporter for MassAssignmentViolations.

Thanks for this PR, and sorry it took a minute to get to it. Because of some large refactorings I've rolled this PR up in #825. Hope you don't mind!


add script for generating new report

In this PR I create a script to make "create new report" easier. All you need is only to execute this command:
yarn new "Title" version "Description" "Author"

For example:
yarn new "React" 19 "React is JavaScript library for building User Interface" "faultable"

Author is referred to your GitHub username, and we use version here for the context because a report of React v16 and React v17 will be different since they have bumped the major version.

Also I create some basic CONTRIBUTING.md file, so people can start contributing (in case they want) and know which file they should read since the README.md doesn't tell it.


Provide a standalone Rally installer

Installing Rally is easy if you're familiar with Python. If you're not, things can get confusing quickly. Many of our users, including Kibana developers, could not care less about Python, and would prefer having a simple executable that embeds CPython and all dependencies. The gold standard here is Go, where binaries are how you ship your code. But we're not going to rewrite Rally in Go :) Instead, we want an installer like the one provided by awscli v2: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html. You just have to unzip and run a simple install script to use it.
Sharp edges
I asked a friend that maintains such an installer. He prefers not to be named, but here's what he had to share (thanks!):

Yeah, it's pyinstaller under the hood. That's been the most straightforward option.
I can give you the sharp edges we've found so far to hopefully save yourself some pain.

AV Vendors do not like when you upgrade PyInstaller. Every time we've done that, it's required going to Microsoft and other vendors to have the allowlist the new binary. So pick a recent version and plan to stay on it for a while.
Given that you're bundling a Python interpreter, you may need to upgrade and backport changes in the event of a CPython CVE. We learned the hard way you want this to be fast and easy.
Linux and Windows are pretty straight forward, but distributing the macOS binary had a somewhat steep learning curve. Mostly around signing, using the right base OS. Elastic may already have those pieces setup though.

(I think only 2 and 3 apply to us here.)
Another thing to watch out for: to provide both esrally and esrallyd, we'll need to use multipackage support: https://pyinstaller.readthedocs.io/en/stable/spec-files.html#multipackage-bundles.
Platforms
We don't support Windows, but we want to support developers on Linux and macOS, as well as running on Linux servers (including ARM). This means we would ideally like to provide packages for:

Linux x86_64
Linux aarch64
macOS x86_64
macOS arm64

However, since pyinstaller is not a cross-compiler, this means we'll need a macOS environment. A good way to automate this is to use GitHub Actions. Since GitHub Actions do not currently provide ARM-based Macs, that means we would only be providing a x86_64 executable. This could be good enough, since ARM-based Macs can run x86_64 executables with Rosetta 2. Not sure how we should go about signing the executable. We can probably start with ad-hoc signing.
We'll have a similar problem for Linux ARM, but at least it's easy to get our hands on a Graviton instance.

PyOxidizer sounds like a more promising approach than PyInstaller, see https://hynek.me/til/python-portable-binaries/

I started experimenting with PyOxidizer yesterday. It supports Python 3.8, 3.9 and 3.10, just like us. It's unclear how long we will have to wait to get 3.11. Many projects that have to deal with the low-level parts of CPython have difficulties supporting Python 3.11, but I'm not sure if it affects PyOxidizer in the same way. Issues I've faced so far:

Rally uses __file__ in a few places which is not supported, see https://github.com/indygreg/PyOxidizer/issues/69 for details
We depend on aiohttp which uses Cython, which required me to opt out of the static builds: https://github.com/indygreg/PyOxidizer/issues/567
We depend on jsonschema that apparently uses pkgutil.get_data incorrectly but in a way that works on CPython: https://github.com/indygreg/PyOxidizer/issues/436

Interesting pull request suggesting additional difficulties on macOS: https://github.com/splitgraph/sgr/pull/656


ML - Azure API warning when connecting to Azure

Azure Data Studio Version:

Steps to Reproduce:

Open import model wizard
select Azure to import model from Azure
login to azure

Expected: Subscriptions should show up successfully
Actual: ADS shows a warning "
A call was made to azdata.accounts.getSecurityToken, this method is deprecated and will be removed in future releases. Please use getAccountSecurityToken instead. "
Subscriptions are loaded finally but warnings keeps showing up

Duplicate of https://github.com/microsoft/azuredatastudio/issues/11718 😄