[$500] Status - Emoji in custom status holder is not centered

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

Version Number: v1.4.33-3
Reproducible in staging?: y
Reproducible in production?: new feature
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal team
Slack conversation:
Issue found when executing PR https://github.com/Expensify/App/pull/34795
Action Performed:

Go to Settings > Profile > Status.
Select a square emoji and save it.
Return to home page.

Expected Result:
The emoji in custom status holder should be centered.
Actual Result:
The emoji in custom status holder is not centered.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01081acf60824f9786
Upwork Job ID:<PHONE_NUMBER>963744768
Last Price Increase: 2024-02-13

cc: @jayeshmangwani

Some emojis are aligned differently on different platforms as right now we are using text to display emojis and it taking space different on platform basis, and I think that was discussed on the original PR.
does we need to fix text of emoji on the platform basis ?
cc: @shawnborton @dubielzyk-expensify @mollfpr

How are we currently handling the alignment? Are we just using text-align: center or something like that here?

Currently we are adding the alignItemsCenter & justifyContentCenter to the parent View of the Text component
https://github.com/Expensify/App/blob/cfb6f2c9b36c28ebc1e78189f65c97278cd885aa/src/styles/index.ts#L3930-L3932

Hmm, I have no idea then.
When we test this with Figma, basically vertically and horizontally centering the text gives us pretty predictable results with centering:

The only thing I could think to do would be to give the emoji text a set line height, height, and width. And then make sure this view also does vertical and horizontal centering?

Some emojis are aligned differently on different platforms as right now we are using text to display emojis and it taking space different on platform basis, and I think that was discussed on the original PR.

I don’t think we can find a quick fix for this. Either way we want to fix this or close it, this shouldn’t be a blocker.

The only thing I could think to do would be to give the emoji text a set line height, height, and width. And then make sure this view also does vertical and horizontal centering?

This is where my mind went too.

I agree this does not have to be blocker

The only thing I could think to do would be to give the emoji text a set line height, height, and width. And then make sure this view also does vertical and horizontal centering?

Right now we are doing similar thing, we have a parent view of 20px height width and alignItems: center and justifyContent: center, with only child emoji text. we have a emoji text size 9 ,we didnt passed the line height, we can pass the lineHeight getValueUsingPixelRatio(9, 15) and do the text align center
cc: @mollfpr

Commented a similar thing in Slack, but how do we do this in other parts of the app where we have emojis? It doesn't seem to be an issue in other parts so while it is smaller in size, I'd love to use similar logic to the emoji reactions etc. If that's possible?

We have only one proposal here https://github.com/Expensify/App/issues/35389#issuecomment-1916811945 from @Krishna2323
But it doesn't have clear rootcause and  assumption to have left spacing to solve the issue.
So still waiting for proposals or suggestions

Clever solution. We'll probably have to play around with the scaling as it can probably be closer to scale(.75), but that's an awesome way to do it. Looks good to me with those examples

We're still waiting on proposals here right?

Yeah, as @dubielzyk-expensify mentioned above, that seems like a clever solution!

Reviewing now

@Krishna2323 Thanks for the updated proposal. I have questions

I am assuming the solution was arrived at a try and error method. Do let me know if there is some root cause/ references for why the transform would work/ is working?
Was this solution tested in all platforms and does it work properly in all platforms?

@Krishna2323 Could you update on the above? https://github.com/Expensify/App/issues/35389#issuecomment-1934762655

Reviewing now

Can we re-test this issue? @kbecciv  I did a 400% zoom on chrome and not seeing any issue

@abdulrahuman5196, I can still reproduce.

@Krishna2323 Is it fixed now for the red square emoji? Or is this present only for certain emoji's?

@abdulrahuman5196, I can still reproduce.

@Krishna2323 Is it fixed now for the red square emoji as I called out? Or is this present only for certain emoji's?

This is what I see in web for the latest dev. Same is happening in staging as well. Am I not seeing the issue? Do let me know if i am missing something here
https://github.com/Expensify/App/assets/46707890/e62ccc9b-fdf3-4242-93ed-579de301bed1
cc: @kbecciv Could you kindly re-check the issue as well from your end?

@Krishna2323 / @kbecciv Could you kindly check on this https://github.com/Expensify/App/issues/35389#issuecomment-1963831960

Hi, @madmax330 Could kindly add BZ here to move this forward?
Still pending on this comment - https://github.com/Expensify/App/issues/35389#issuecomment-1970910694

I'm not able to reproduce and @kbecciv has been unresponsive on the pings within this GH.
I'll apply the retest weekly label.

this is being retested weekly to see if this is still an issue.

this is being retested weekly to see if this is still an issue.

Issue is reproducible during KI retests.
https://github.com/Expensify/App/assets/43995119/82c01c09-becb-4cef-933c-4c13b28f1b93

This is one that I was just assigned. It looks like we confirmed in Jan that this was an issue.
Once I was assigned I applied the re-test weekly label to see if this was still occurring. @mvtglobally confirmed.
@abdulrahuman5196 I see that several proposals came in. Are any a viable fix?

@abdulrahuman5196 have you had a chance to review the proposals for this one?

Checking now

@Krishna2323 I am having hard time in testing/seeing your solution working.

Could you kindly update your proposal as per the latest solution suggested by you?
(Not a normal case)Kindly share code sample of your change so that I can confirm as you claim, since its not working for me? I assume it should be very quick code.

@puneetlath I'm ooo until April 08 - I'll be taking back any Open issues upon my return

CURRENT STATUS:
Still looking for an acceptable proposal.

@Krishna2323 can you please address the questions form @abdulrahuman5196 above: https://github.com/Expensify/App/issues/35389#issuecomment-2009677459

Gentle ping @Krishna2323

Looks like we are still waiting for a working proposal here. Is that right @abdulrahuman5196?

Proposal
Please re-state the problem that we are trying to solve in this issue.
There are two issues here:

Status - Emoji in custom status holder is not centered
In Safari, the icon width is rendered as 12 pixels instead of the font size of 9 pixels, causing Safari to display a larger icon.

What is the root cause of that problem?
Different browsers and devices may render fonts and native emoji in varying ways.
This problem occurs under the following conditions:

Zooming in on the page using a trackpad swipe with two fingers moving in opposite directions. Zooming via cmd++ or cmd+- or using dev tools responsive tools will not trigger this issue.
Font size is below 12px.
Using a chromium based browser (chrome, edge, electron).

This issue may also occur in our desktop version if the zoom is activated, although it is disabled by default.
                browserWindow.webContents.setVisualZoomLevelLimits(1, 5)

If the above criteria are met, the emoji text will introduce additional white space to the right of the emoji.
What changes do you think we should make in order to solve the problem?
Use a 12px font size as the default.
If we set the default font size to 12px, the issue will be resolved. We can maintain 9px font size for Safari, as it will be displayed as 12 pixels there. We can use Browser.isSafari() to verify this.
For native, it is advisable to stick with 9 pixels as using 12 pixels will cause overlap with the surrounding circle. To ensure this, utilize lodashIsEmpty(Browser.getBrowser()).
Modify the emojiStatusLHN style to:
        emojiStatusLHN: {
            fontSize:  Browser.isSafari() || lodashIsEmpty(Browser.getBrowser()) ? 9 : 12,
        },

Or if we only need to keep 9px as default and only change chrome desktop
        emojiStatusLHN: {
            fontSize:  Browser.isChrome() ? 12 : 9,
        },

This solution will address both issues described above.
What alternative solutions did you explore? (Optional)
Alternative 1 - Disable pinch-to-zoom
Using user-scalable=no and maximum-scale=1 properties in the viewport meta tag were initially meant to prevent zooming in browsers. However, various modern browsers, such as Chrome, now disregard these properties to enhance accessibility for users. Implementing a JavaScript solution for this option is more reliable, but we have to ensure not to create regression for other touch events.

[!warning]
Disabling zooming can make it difficult for users with visual impairments to read and interact with web content.

Example implementation

let initialDistance = 0;
let isPinching = false;

document.addEventListener('touchstart', function(e) {
    if (e.touches.length === 2) {
        initialDistance = Math.hypot(
            e.touches[0].pageX - e.touches[1].pageX,
            e.touches[0].pageY - e.touches[1].pageY
        );
        isPinching = true;
    }
});

document.addEventListener('touchmove', function(e) {
    if (e.touches.length === 2 && isPinching) {
        const currentDistance = Math.hypot(
            e.touches[0].pageX - e.touches[1].pageX,
            e.touches[0].pageY - e.touches[1].pageY
        );
        if (Math.abs(initialDistance - currentDistance) > 10) {
            console.log('Pinch-to-zoom gesture detected');
        }
    }
});

document.addEventListener('touchend', function(e) {
    if (isPinching) {
        isPinching = false;
    }
});

Alternative 2 - Create minimum reproducible example, send to chromium team and let them decide.

[!warning]

They might not treat our issue as a bug, and might just close it
The ETA is can't be decided, if they decided to fix it, we should also ask electron team to bump the chromium version, I can imagine really-really long journey
I hope I can get compensated proposing this option

Alternative 3 - Use image emoji
We can improve control over image emoji rendering on different browsers, but it could result in significant alterations to this overly complex solution.

Seems we have new proposals. Will review today.

@abdulrahuman5196 thoughts on the proposals?

Issue not reproducible during KI retests. (First week)

@mvtglobally Please use the trackpad/touchpad to zoom in, not cmd++
Reproducible with the latest staging
https://github.com/Expensify/App/assets/11847279/cb6a02c7-6be2-44cf-a29f-b1b7ce40aee7

@abdulrahuman5196 bump on reviewing the proposals.

@abdulrahuman5196 are you able to reviewing the proposals above?

Hi, will review on the proposals in my morning

@abdulrahuman5196 it's been 8 days since you first stated you would review the proposals. Will you be able to get them reviewed asap?

@abdulrahuman5196 it's been 8 days since you first stated you would review the proposals. Will you be able to get them reviewed asap?

@abekkala  Hi, Yesterday I tried again and the same issue happened. Let me try again now and attach videos here.

@abdulrahuman5196, pls try changing the emojiStatusLHN style to:
        emojiStatusLHN: {
            transform: 'scale(.8)',
            lineHeight: 16,
        },

@Krishna2323 I tried this one, seems to be working fine for web chrome, but causing the below issue in native. The icon is getting clipped.

@wildan-m I tried your suggestion of
        emojiStatusLHN: {
            fontSize:  Browser.isSafari() || lodashIsEmpty(Browser.getBrowser()) ? 9 : 12,
        },

But its not working in safari mobile. Causing below issue.

Sorry for the delay. I will keep the issue on priority. Will check once we have response from contributors. Currently we don't have any proposal to approve.

@abdulrahuman5196 can you specify what issue in the image? seems that's expected result?

@abdulrahuman5196 the solution doesn't change safari font size, so it will be the same before and after

before
after

@wildan-m  The issue is that the emoji is not centred on safari. We should check for a solution to work on all platforms.

@Krishna2323 kindly do check and provide updates on the above query.

@kbecciv can you re-confirm whether the issue also occurred on safari? I can only reproduce it in chrome

@abdulrahuman5196 which iPhone emulator version did you use? It seems to have different results when using iPhone 15 plus ios 17.

@abdulrahuman5196 My Proposal updated
It makes slight adjustments for better consistency. Please try and let me know:
        emojiStatusLHN: {
            fontSize:  Browser.isSafari() || lodashIsEmpty(Browser.getBrowser()) ? 9 : 12,
            lineHeight: lodashIsEmpty(Browser.getBrowser()) ? undefined : 17,
            marginLeft: 0.375,
        },

We can split into platform-specific code if necessary.

@wildan-m Even for me currently occuring in staging for ios safari

Are you sure you are using the trackpad with two fingers moving in opposite directions and not cmd + +?
I can clearly spot it in chrome https://github.com/Expensify/App/issues/35389#issuecomment-2036115675

@abdulrahuman5196 can you review the updated proposal

@abekkala / @dubielzyk-expensify I think the updated proposals are becoming kind of a loop of trial and error approaches.
I don't see a solid solution perfectly working in all platforms.
Should we go with a solution which is working in most cases? Or what should be the approach we choose here since the issue is already very old?

@abdulrahuman5196
I believe the most viable solution is my alternative 3 solution (using image emoji). I attempted to substitute the emoji with a static image, and the outcome was perfectly centered without any need for adjustment. Slack also renders its emoji as images, but I suspect this solution might not be accepted due to the potential for too many alterations.
<img src="https://images.emojiterra.com/google/noto-emoji/unicode-15.1/color/svg/1f7e5.svg" alt="Google (Noto Color Emoji - Unicode 15.1)" width="9" height="9" style="/* vertical-align: middle; */">

Have a look at this issue. The issue also ended with kind of a loop of trial and error approaches playing with line height.

@abekkala / @dubielzyk-expensify I think the updated proposals are becoming kind of a loop of trial and error approaches.
I don't see a solid solution perfectly working in all platforms.
Should we go with a solution which is working in most cases? Or what should be the approach we choose here since the issue is already very old?

Need folks to check on this.

@dubielzyk-expensify
I'll defer to your engineering opinion on this from @abdulrahuman5196

I don't see a solid solution perfectly working in all platforms.
Should we go with a solution which is working in most cases? Or what should be the approach we choose here since the issue is already very old?

Can I get a series of screenshots with some emoji's to see how it looks at the moment? Or a PR I can try locally?

@dubielzyk-expensify you can try my branch here.
Please also add test case when we zoom the page using trackpad like https://github.com/Expensify/App/issues/35389#issuecomment-2036115675

There's definitely some bleed out of the container on the bigger emojis, but I think this is the best we've gotten. At this size I don't think we'll get it better given we either have to shrink it down or deal with the bigger ones specifically.
I actually prefer that than to turning on overflow hidden. Here's my test cases:

Keen to hear if @Expensify/design team agrees.

The bug started out not being centered and looking off. And now I think it actually is fixed. There's perhaps some 0.1px or so positioning we could do but I think it looks good

I guess if we are worried about the slight overflow, we can just bump the font size down slightly in this specific scenario? Otherwise it looks good to me, and I much prefer using a solution that does not introduce images/svgs and instead just uses the native emoji fonts if possible.

@dubielzyk-expensify @shawnborton in my analysis, it should have at least 12px to make the font not add padding in the right side.
Another consideration is -- safari render the 9px font as 12px, so it's seems bigger.
More details ablut the analysis: https://github.com/Expensify/App/issues/35389#issuecomment-2027896482

Have you tried using a larger font size, but applying a scale transform to shrink it back down? I wonder if that could yield some interesting results.

Have you tried using a larger font size, but applying a scale transform to shrink it back down? I wonder if that could yield some interesting results.

@shawnborton Yes, I had, it will appear cut off in the right when in normal zoom level.

Okay cool, welp that was my only idea 🤣

So it sounds like the path forward is to shrink the font-size ever so slightly (feel free to use .) so the examples here are fitting within the circle. Otherwise, I think we can move ahead.
I did what @shawnborton suggested in dev and added transform: scale(0.9) on the text only and it seemed to work well?

@dubielzyk-expensify did you zoom the browser?
Try taking a screenshot without zooming the browser.
I have not tested all emojis, but it may be noticeable with wide, rounded emojis like the compass 🧭
Take a look at this screenshot, although small, I see that the right side is not perfectly round due to using transform: scale(0.9). If that is acceptable, then we can add that scale.

Ahh okay, good find! Let's just reduce the font size then or whatever we need to do so that the big emojis don't break the bounds of the circle 😄

Is it okay to increase the round wrapper by 1 px (20px => 21px)?
if ok the line height will be 18px (not 17px)
and here is the result

I'll let @Expensify/design chime in here. I don't feel strongly

What do you mean by increase the round wrapper?
Also, I want to clarify that I am suggesting the scale method as I understand that the emojis seem to render better at larger font sizes. So I wasn't really thinking it would be used for minor adjustments (scale .9 for example) but rather, you could display the emojis at something like 24px font size but scale down to .5 if we really needed them to show at what feels like 12px font size.

@shawnborton

What do you mean by increase the round wrapper?

Also, I want to clarify that I am suggesting the scale method as I understand that the emojis seem to render better at larger font sizes. So I wasn't really thinking it would be used for minor adjustments (scale .9 for example) but rather, you could display the emojis at something like 24px font size but scale down to .5 if we really needed them to show at what feels like 12px font size.

I doubt that would work, since our target is 9 px, here is the result using fontSize: 18px and transform:scale(0.5)

I don't think we should change the size of the round wrapper. Let's keep it at 20px.
This is more so how I was envisioning scale... Basically we need to do some more tricks to get it to work correct, take a look at some of the styles I applied here:

Also unrelated to the emoji, we need to fix the border color around the emoji wrapper:

Proposal
Please re-state the problem that we are trying to solve in this issue.
Status - Emoji in custom status holder is not centered
What is the root cause of that problem?
macOS's text rendering engines interpret CSS properties like line-height and padding differently, leading to emojis appearing off-center. The minimal width ratio compared to the line height here is 3:4, causing the bug since it is wider then an emoji.
What changes do you think we should make in order to solve the problem?
I calculated the differences in the ratio, and adjusting the CSS fixed the problem. Also, we would have to ensure that these CSS changes are only applied on platforms mentioned in the bug, to avoid displacement in other ones.
What alternative solutions did you explore? (Optional)
NA

@shawnborton I'm not sure why it appears differently in my Chrome with your applied style. Did you make any other changes?

Hmm only thing I can think of is to add overflow: hidden to the parent wrapper and see if that helps?

No effect on my end. In staging, is it still functioning correctly on your side?

       emojiStatusLHN: {
            fontSize: 9,
            paddingLeft: 1.5,
            lineHeight: 10
        }

This seems to fix the problem for me. @wildan-m @shawnborton could you try it as well

@Nuka02 I'm not a C+, but @abdulrahuman5196 might be able to help.
Does your solution works when we zoom in/out the page using trackpad like https://github.com/Expensify/App/issues/35389#issuecomment-2036115675 ? (should use trackpad, not using cmd++)

@Nuka02 I'm not a C+, but @abdulrahuman5196 might be able to help.
Does your solution works when we zoom in/out the page using trackpad like #35389 (comment) ? (should use trackpad, not using cmd++)

Yes, the screenshots I sent above are zoomed in using trackpad.

checking again

Hmm yeah, I don't think my scale idea is working well on a second look. Here are some of the crazy adjustments it's taking to get something to render nicely, all of which seem way too hacky:

And this is just Chrome too, who knows how this would even work on iOS or Android. So yeah, I think we should consider a better approach :)

Hmm yeah, I don't think my scale idea is working well on a second look. Here are some of the crazy adjustments it's taking to get something to render nicely, all of which seem way too hacky:

And this is just Chrome too, who knows how this would even work on iOS or Android. So yeah, I think we should consider a better approach :)

Have you tried my solution above?
Also, note that I would apply those changes only on the two platforms having the issue. The other ones will remain the same

I have not tried that, will let @abdulrahuman5196 & @madmax330 comment on that one.

I am not aligned on @Nuka02's suggestion here https://github.com/Expensify/App/issues/35389#issuecomment-2084075252.
It is not that every emoji is not centered, it mostly happens for bigger emojis AFAIK, do correct me otherwise. So moving the emoji a little left/right with padding might not be good.

Hmm yeah, I don't think my scale idea is working well on a second look. Here are some of the crazy adjustments it's taking to get something to render nicely, all of which seem way too hacky
And this is just Chrome too, who knows how this would even work on iOS or Android. So yeah, I think we should consider a better approach :)

Hi @shawnborton , AFAIS the only better approach than that from the proposals so far is to reduce the emoji size with font-size property. Do you think that should be fine?

There's definitely some bleed out of the container on the bigger emojis, but I think this is the best we've gotten. At this size I don't think we'll get it better given we either have to shrink it down or deal with the bigger ones specifically.

I agree with @dubielzyk-expensify 's comment. I am not sure if we would get a better approach at this point. And we should choose the best approach as we have now. I think reducing size would be better, but anyways I think design team would be the best to answer this.

Cool, I can totally get down with that then. I agree, we're kinda out of great options so let's just take the best incremental step here that we can.

Based on this https://github.com/Expensify/App/issues/35389#issuecomment-2085405861 and this  https://github.com/Expensify/App/issues/35389#issuecomment-2085403335 we should be reducing the font-size on the affected platform to reduce the overflow.
The first suggestion to modify/reduce font-size came from @Krishna2323 here https://github.com/Expensify/App/issues/35389#issuecomment-1925350730 AFAIK. @Krishna2323 Kindly update your original proposal as well based on your recommendation.
🎀 👀 🎀
C+ Reviewed

Gentle ping @madmax330 / @dubielzyk-expensify

Yeah, I'm okay with that. For me reducing the fontsize was okay, but I know we ended up with some funky values. You alright with this @shawnborton given that the scaling solution didn't work

Yup, I'm down to try something different here!

@Krishna2323 payment sent and contract ended - thank you! 🎉

The PR that introduced the bug has been identified. Link to the PR:
The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

Not a regression.

Determine if we should create a regression test for this bug.

Yes.

If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Go to Settings > Profile > Status
Select a square emoji and save it
Return to home page
Verify it is centered

@abekkala

@abdulrahuman5196 payment sent and contract ended - thank you! 🎉


[Mobile] Option to display all the data in app including format instead of just plain text

My issue is about [Mobile]
Basically, according to the documentation, we can add documents by encoding to delta and then to json. And to display it back in the quill, we just decode it and pass it back to the quill controller. But to show this data on app say on gridview like a note, we have to use toPlainText which removes all the formatting.
Can you add an option to keep the formatting here? or is there already an option?
I have tried running example directory successfully before creating an issue here.
Please note that we are using latest flutter version in stable channel on branch master. If you are using beta or master channel, or you are not using latest flutter version in stable channel, you may experience error.

Are you asking to expose some method?

var json = jsonEncode(_controller.document.toDelta().toJson());

That method encodes it and stores as json which can only be viewed back in only quill editor.
But I am asking for a method that can store data with formatting.

Take the json string and do your processing to get what you need

That method encodes it and stores as json which can only be viewed back in only quill editor.
But I am asking for a method that can store data with formatting.
Something like:
var data= _controller.document.toFormatted();

And this can be displayed in text
Text(data)

Alright I think you can create a PR if you really want it.
Just follow how toPlainText is done


Fixed the problem of incorrect remote host IP in connection history a…

Unable to obtain real remote host IP after reverse proxy,If the proxy request header exists, the real IP will be obtained from the request header, otherwise the IP will be obtained through the original method.

For this change to move forward with providing the quality-of-life improvements intended (without introducing a security issue), the change would need to:

Effectively re-implement what Tomcat already provides with RemoteIpValve via more convenient configuration properties, ensuring the admin has full control over how and whether X-Forwarded-For is used.
Use a servlet filter or similar to guarantee that getRemoteAddr() returns the expected address when the HTTP request is directly inspected (third-party libraries like those used for SAML will otherwise not be affected by the additional configuration and would still not see the expected address without RemoteIpValve).

@LemonZuo If you want to give that a shot, the change would need to be made to the webapp, not guacamole-ext. If done correctly, Credentials and anything else using standard functions like getRemoteAddr() would see the expected address.


perf: optimize toArray

Current dependencies on/for this PR:

master

PR #13   👈

PR #14

PR #15

PR #16

This comment was auto-generated by Graphite.

⏳ This pull request is set to merge as part of a Graphite merge job
Job ID: mlWx2WhC8q5R6P9NpkN5.
See details on graphite.dev


Add serialization-lib fork to nix

We need https://github.com/SundaeSwap-finance/cardano-serialization-lib available in node_modules before #44 can be merged. The upstream version of serialization-lib diverges from it enough to break the test suite.

By far the easiest way to solve this was to just fork Sundae's fork and then publish it to NPM. The build system is pretty complex and it would be quite a pain to try to wrap the whole thing in a Nix derivation instead of just getting it from NPM
I forked the fork and published: https://www.npmjs.com/package/@ngua/cardano-serialization-lib-nodejs (also published the browser build target)


⚠ Mobitopup has degraded performance

In f71d02a, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 5278 ms

Resolved: Mobitopup performance has improved in a948070.


Deactivate travis push builds

One usually only needs merge PR builds and not building pushes speeds up the merge process.
Just a recommendation :) I usually do that for all my repos.

Done

I've just noticed this doesn't test merged builds. I'm re-enabling this now


Feature Request: Chinese (Simplified and Traditional) and Japanese Language Analyzer

Hi there,
I found this great app on reddit and am trying it out, both on your public cloud and on local dev machine using docker. Now I 'd like to ask if you can add the language analyzer for Chinese (Simplified and Traditional) and Japanese?
The CJK are some tricky languages to deal with and here's what I found on stackoverflow regarding the Chinese and Japanese language analyzers: http://stackoverflow.com/questions/29098347/elasticsearch-cjk-language-analyser. Sadly there isn't one for Korean yet.
I also want to curious about how well the current Tesseract OCR tuning included in ambar works with CJK languages.
Thanks.

Done


Option to commit directly to target branch

Is your feature request related to a problem? Please describe.
Having the action constantly create PRs is annoying.  I want to be able to run a cron task (the cron part would be handled by actions itself, not this action) that just directly commits translation updates, instead of creating a PR.
Sure, I could create an auto-merge workflow, but that still would send out emails, which is just annoying.
Describe the solution you'd like
An option to commit new changes directly to the target branch.
Describe alternatives you've considered
Auto-merge PR workflow - see above.

Hi @RDIL
Thanks for the idea, we'll consider whether it's possible to implement it.

Hi @RDIL,
please try specifying the step configuration:
- name: crowdin action
   uses<EMAIL_ADDRESS>   with:
     upload_sources: true
     download_translations: true
     push_translations: true
     commit_message: 'New Crowdin translations by Github Action'
     localization_branch_name: main
     create_pull_request: false

It worked, thanks @andrii-bodnar!


Typo in lazy loading with lambda usage section

public ICollection<Post> Posts
{
    get => LazyLoader?.Load(this, ref _posts); // should be 'Invoke(...)' here
    set => _posts = value;
}

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

ID: bbd36f35-e257-d0ed-8f28-f539ddcb71ec
Version Independent ID: 093903d5-f7c7-5a78-c0e5-0e2662dcedef
Content: Loading Related Data - EF Core
Content Source: entity-framework/core/querying/related-data.md
Product: entity-framework
GitHub Login: @rowanmiller
Microsoft Alias: divega

@Alazari-main Can you explain why you think Invoke is needed/better here?

@ajcvickers, Yes, I can. Because I took this code from section where "LazyLoader" is provided as a Delegate (Action<object, string> in our case) and there is no Load method for the Action delegate

@Alazari-main The doc says, "The code above uses a Load extension method to make using the delegate a bit cleaner:" and then shows the extension method.

Ok. I'm blind. There was a misunderstanding from my side. Thank you for an explanation


Azure AD group members adapter

This PR adds a new adapter for Azure AD that enables syncing users to an AD group.

Looks like the linter is failing some of the auto-generated mock code. Specifically gci is missing the --skip-generated flag.
I can fix the generated code but that feels like a smell to me. I think it's probably a good idea to ignore anything auto-generated with the linting instead - thoughts @jlucktay @mike-gregory-ovo ?

Looks like the linter is failing some of the auto-generated mock code. Specifically gci is missing the --skip-generated flag.
I can fix the generated code but that feels like a smell to me. I think it's probably a good idea to ignore anything auto-generated with the linting instead - thoughts @jlucktay @mike-gregory-ovo ?

This looks like the same issue that causes the generated code to constantly fall out of alignment on the O2B tooling repo. If so, I think it's the Makefile targets being run in the wrong order.
The lint-fix target is already in there to straighten things like this out, so the dependencies just need a bit of rearranging. I'll make a branch and try to remedy it.

@chris-brindley #236 should sort it.

@mike-gregory-ovo I think this PR is ready for a review following the fix @jlucktay implemented in the Makefile.


Feature/3299 diagnostics chainset

Submission Checklist

[x] Run unit tests: ./runTests.py src/test/unit
[ ] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary
This PR uses the improved R-hat diagnostics (https://github.com/stan-dev/stan/pull/3266) and extends rank-normalization to the computation of ESS-bulk and ESS-tail.   These diagnostics are computed on samples from one or more chains, which entails parsing the sample out of a stan-csv file and assembling it into an Eigen MatrixXd object.
The work done for this PR is:

refactoring of the functionality in stan/analyze/mcmc so that both ESS and Rhat can use rank-normalization
addition of a new class stan/mcmc/chainset.hpp which stores a set of samples as a std::vector of Eigen MatrixXds.
changes to the stan_csv_reader to fix bug https://github.com/stan-dev/stan/issues/3301, and to distinguish between ADVI and NUT-HMC samples (because CmdStan PR https://github.com/stan-dev/cmdstan/pull/972 was done in order to get summaries from ADVI outputs).

Intended Effect
The consumer of this functionality is CmdStan's stansummary utility, which, given a list of Stan CSV filenames, assembles them into a chainset object and then calls functions on the chainset object to get summary stats and diagnostics.
How to Verify
unit tests in this repo; unit tests in CmdStan repo test end-to-end parsing and reporting
Side Effects
N/A
Documentation
Documentation for CmdStan bin/stansummary to be done in docs repo, and CmdStanPy docs (CmdStanPy's summary function wraps CmdStan's stansummary).
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Columbia University
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

CmdStan tests failed - correctly!
offending test is here:  https://github.com/stan-dev/cmdstan/blob/33e27a4f7b72c7df558d982a33bfe33ce0b14211/src/test/interface/variational_output_test.cpp#L53
ADVI output format is 1st line is the ADVI estimate, followed by 1000 samples.
summary of samples should only look at the sample, not the ADVI mean.

Created a new PR because accidentally included some version of Stan math_lib in #3305 and don't have the GitHub chops to undo its fubarness.

Seems like a good move. Only downside is we lost the review history, which makes it difficult to track what has changed

agreed - will continue to add in changes suggested/requested in #3305

Sounds good! Could you ping me when you think all of the 'old' review is resolved and I can take a look at the branch then?

@WardBrian @SteveBronder I've made changes and have a branch of CmdStan that works with updated code.
can this go in today?

I'm not sure why any changes were made to chains.hpp -- just deleting dead code?

https://github.com/stan-dev/stan/pull/3266 added call for split r-hat to chains.hpp
when I first started working on this PR, I thought that we could add rank-normalized ESS and MCSE to chains.hpp as well.
I can revert chains.hpp to the state that it was in before #https://github.com/stan-dev/stan/pull/3266.

I'm pretty nervous about changing both the code organization and the behavior at the same time (see above on quantiles, etc). It also means we can't test the new one against the old one

we know that the behavior will be different because the old version was implemented before the 2019 improved r-hat paper came along.   for this PR, I ran the example output CSV files through CmdStanR, which uses posterior, which provides a correct implementation of the rank-normalized rhat.  (Aki / Paul Beurkner / Johah ).

I'm not referring to the new ESS/R-Hat in that comment -- those are entirely new things being computed and reported to the user. But it does seem weird (and potentially impactful) if the 95% interval changes based on just updating stansummary and running on the same outputs as before

this is what the quantile code from chains.hpp computes:
    using boost::accumulators::accumulator_set;
    using boost::accumulators::left;
    using boost::accumulators::quantile;
    using boost::accumulators::quantile_probability;
    using boost::accumulators::right;
    using boost::accumulators::stats;
    using boost::accumulators::tag::tail;
    using boost::accumulators::tag::tail_quantile;
    double M = x.rows();
    size_t cache_size = M;

    if (prob < 0.5) {
      accumulator_set<double, stats<tail_quantile<left> > > acc(
          tail<left>::cache_size = cache_size);
      for (int i = 0; i < M; i++)
        acc(x(i));
      return quantile(acc, quantile_probability = prob);
    }
    accumulator_set<double, stats<tail_quantile<right> > > acc(
        tail<right>::cache_size = cache_size);
    for (int i = 0; i < M; i++)
      acc(x(i));
    return quantile(acc, quantile_probability = prob);
  }

the new code is more efficient - but possibly different behavoir.
your call on what to do.

the new code is more efficient

Do you have timing on that? The latest commit seems to just call quantile in a loop, so I'd expect them to end up pretty much even

but possibly different behavoir.

Definitely different -- here's a super minimal CSV file:
foo
100
101
102
103
104
105
106
107
108
109
110

current stansummary:
      Mean  MCSE  StdDev  5%  50%  95%  N_Eff  N_Eff/s  R_hat

foo    105   1.8     3.3 100  105  110    3.4      inf    2.8

the cmdstan PR based on this branch:
      Mean  MCSE  StdDev  MAD   5%  50%  95%  N_Eff_bulk  N_Eff_tail  R_hat

foo    105   1.5     3.3  4.4  100  105  109         5.0         5.0    2.1

this is not surprising - the super-minimal CSV file has 10 rows.  we're advertising different computation.  we do this all the time.

also, trying to run minimal CSV file  "foo.csv" through bin/stansummary from 2.35.0 release bombs.  how did you run this test?

here's another test:  current release vs new branch - quantiles are the same.
 ~/.cmdstan/cmdstan-2.35.0> bin/stansummary src/test/interface/example_output/bernoulli_chain_1.csv
Inference for Stan model: bernoulli_model
1 chains: each with iter=(1000); warmup=(0); thin=(1); 1000 iterations saved.

Warmup took 0.0090 seconds
Sampling took 0.023 seconds

                Mean     MCSE   StdDev     5%   50%   95%  N_Eff  N_Eff/s  R_hat

lp__            -7.3  3.7e-02     0.77   -9.1  -7.0  -6.8    443    19275    1.0
accept_stat__   0.90  4.6e-03  1.5e-01   0.57  0.96   1.0   1026    44597   1.00
stepsize__       1.0      nan  4.9e-15    1.0   1.0   1.0    nan      nan    nan
treedepth__      1.4  1.6e-02  4.9e-01    1.0   1.0   2.0    895    38919   1.00
n_leapfrog__     2.3  3.4e-02  9.6e-01    1.0   3.0   3.0    799    34758   1.00
divergent__     0.00      nan  0.0e+00   0.00  0.00  0.00    nan      nan    nan
energy__         7.8  5.1e-02  1.0e+00    6.8   7.5   9.9    411    17865    1.0

theta           0.26  6.1e-03     0.12  0.079  0.25  0.47    384    16683   1.00

new version:
(base) ~/github/stan-dev/cmdstan (feature/1263-new-rhat-summary)> bin/stansummary src/test/interface/example_output/bernoulli_chain_1.csv
Inference for Stan model: bernoulli_model
1 chains: each with iter=1000; warmup=1000; thin=1; 1000 iterations saved.

For each parameter, N_Eff_bulk and N_Eff_tail measure the effective sample size
for the entire sample and for the the .05 and .95 tails, respectively,
and R_hat_bulk and R_hat_tail measure the potential scale reduction
on split chains, (at convergence will be very close to 1).

I have checked the existing unit tests and the behavior on real output files.   I think this is OK.

I’m not saying we’re obligated to report the same numbers from now until the end of days, but I just think if we do make a change we should have a reason why the new number is better/more correct, not just that we like the code that calculates it more

The quantiles shouldn't change.  But the R-hat and ESS will.  That's one of the motivations for the PR---to switch over to our improved versions of these as described in this paper:
Vehtari, Gelman, Simpson, Carpenter, Bürkner. 2019.
Rank-normalization, folding, and localization: An improved Rˆ for assessing convergence of MCMC
https://arxiv.org/abs/1903.08008
I believe @avehtari has already switched over RStan and PyStan and we're just waiting for this PR to switch over CmdStan and hence CmdStanPy and CmdStanR.  I believe arViz also does these new calculations.
We could keep our old definitions and report two versions of R-hat (old, old per second, new) and three versions of ESS (old, new bulk, new tail), but I think it'd be confusing for users.

As another comment, I don't think we should be reporting ESS for sampler parameters other than lp__.

I believe @avehtari has already switched over RStan and PyStan and we're just waiting for this PR to switch over CmdStan and hence CmdStanPy and CmdStanR. I believe arViz also does these new calculations.

CmdStanR can call CmdStan diagnostics, but CmdStanR is also using posterior package, which has new Rhat and bulk- and tail-ESS, and it is more handy to use posterio package diagnostics than CmdStan diagnostics. ArviZ, which is used by Python and Julia users, has these new functions, too. RStan is not yet using posterior package.

We could keep our old definitions and report two versions of R-hat (old, old per second, new) and three versions of ESS (old, new bulk, new tail), but I think it'd be confusing for users.

The old ESS which (called ess_basic() in posterior package) is still needed for computing MCSE for mean estimate. I think the issue is that reporting everything by default would be too much, but CmdStan doesn't have a nice way for the users to define which diagnostic quantities they want to see, and thus we need to make some choices.

As another comment, I don't think we should be reporting ESS for sampler parameters other than lp__.

I agree. Same for Rhat.

The quantiles shouldn't change.

My point is, they do. I believe the test cases we are using are not specific enough to see that, but doing a bit of testing on the side:

Running the bernoulli model
Running the current stansummary and this branch's version, with some extra decimals to be able to actually tell the difference
On basically every run I've observed so far, they disagree on the 50% quantile by the 4th decimal place

Here's a CSV file: https://gist.github.com/WardBrian/41bbf1b57829efa32e6aa58c5c493f57
Current stansummary (with --sig_figs=4)
                     Mean       MCSE     StdDev         5%        50%        95%  N_Eff    N_Eff/s      R_hat
theta           2.593e-01  7.266e-03  1.251e-01  8.379e-02  2.429e-01  4.830e-01  296.7      59330      1.003

new stansummary (with --sig_figs=4)
                  Mean       MCSE  StdDev      MAD       5%     50%     95%  N_Eff_bulk  N_Eff_tail   R_hat
theta           0.2593  7.263e-03  0.1251   0.1343  0.08379  0.2425  0.4830       296.9       446.6   1.008

0.2429 != 0.2425
CmdStanPy uses --sig_figs=6 by default, so end users will see different numbers.
Again, we can decide we want to make this change, but it just happening incidentally doesn't sit right with me, hence me not merging as-is.

N_Eff_bulk  N_Eff_tail

It would be better to use terms ESS_bulk and ESS_tail, as 1) N has different meaning in the paper describing these quantities, and 2) N_eff makes people to misread it as "Number of EFFective samples" which is wrong, and the correct term is "Effective Sample Size"

The old ESS which (called ess_basic() in posterior package) is still needed for computing MCSE for mean estimate.

@avehtari  - could you check the implementations of mcse and mcse_sd?
https://github.com/stan-dev/stan/blob/dbf6a9f80ae2cd38e64fb627080ead01bc81dad7/src/stan/mcmc/chainset.hpp#L424-L467

@WardBrian regarding the implementation of quantiles, we need a better understanding how the boost accumulators library computes quantiles - it is returning the value of a the nth draw or interpolating?  and which is appropriate?
I spent yesterday looking at the boost code and don't understand it well enough to make that call.   changing to use C++ std::nth_element would make the code easier to understand and remove dependencies, but as you say, that's not a good reason to change behavoirs.

I suspect the difference may just be as simple as the existing code prioritizes counting from the left if you're requesting the 50% or higher quantile, but I agree the boost reference is pretty opaque in this area

There is also stan::math::quantile -- calling this would probably be the ideal thing to do from a code standpoint, but it yields yet a third set of numbers...

The quantiles shouldn't change.

I spoke too soon.  The problem with quantiles is that reasonable definitions can differ.   When you don't have an exact item, a lot of algorithms are going to interpolate, and how you do that can differ.  For example if you only have two numbers [1, 3] and ask for a 50% quantile (i.e., a median), what is the answer?  You could return 1 or 3, which is what you get if you turn 50% and the size of 2 into an index.  Or you could interpolate between 1 and 3 and return 2.  The problem's the exact same thing at an edge, but it might not be 50%.  What do you do if I ask you for a 40% quantile of [1, 3]?  There you might be tempted to linearly interpolate and say 1.8.  That interpolation can often be made more stable if you use more elements around an element, so if we have four elements [2, 3, 5, 10], we might return a different answer than [3, 5] for the 50% quantile.  It's a mess!
The bottom line, though, is that in these situations, we really don't care.  The sampling algorithm didn't have the granularity to cleanly resolve the quantile so if we use one of the neightboring values or interpolate, it should be fine for our use.

There is also stan::math::quantile -- calling this would probably be the ideal thing to do from a code standpoint, but it yields yet a third set of numbers.

See above.  That should also be fine.  Using a quantile function that works on a sorted list will be faster if we do a lot of quantiles.  Otherwise, using an accumulator boost style will be faster.  With an accumulator, if you are looking for the rank K element in a list, there's an O(N * log2(K)) algorithm (N for considering each element, log2(K) to insert it into position in the accumulator) that only consumes log2(K) memory.  It can get even more clever than that, see, e.g., the variants available here:
https://www.boost.org/doc/libs/1_86_0/doc/html/accumulators/user_s_guide.html#accumulators.user_s_guide.the_statistical_accumulators_library

Calling stan::math::quantile seems like the best choice then. The code can also be made quite simple:
    Eigen::MatrixXd draws = samples(index);
    Eigen::Map<Eigen::VectorXd> map(draws.data(), draws.size());

    return stan::math::quantile(map, prob);

There is an overload for if prob is a single number or if it is a vector

plugged most recent version of this branch into CmdStan and comparing CmdStanR's summary (via fit$print) against CmdStan's bin/stansummary on the test CSV files in cmdstan/src/test/interface/example_outputs and median and quantile values, as well as mean, sd, mad, ess, and rhat all match out to 9 digits.

comments look great - thanks!  per discussion with @SteveBronder, I think the way to proceed here is with 3 PRs:

fix issues with stan_csv_reader
refactor code added to stan::analyze::mcmc in https://github.com/stan-dev/stan/pull/3266 to add ESS_bulk, ESS_tail and MCSE calculations (to chains.hpp)
add chainset.hpp to code base; a replacement for chains.hpp.

I think 3 PRs would be better - a lot of work, but the grown-up thing to do here.  (especially since I've been advocating pragmatic programming lately).

@avehtari - could you check the implementations of mcse and mcse_sd?

These should use ess_mean without rank normalization. The rank normalized versions are generic diagnostics that work also with infinite variance, but by definition of MCSE mcse_mean and mcse_sd should not use rank-normalization.

closing this per above comment - https://github.com/stan-dev/stan/pull/3310#issuecomment-2389091218


[ExpressRoute] Changes to allow for clarity on S2S over private peering steps

@ShachafGoldstein : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Note that publishing in this repository is suspended until Tuesday, March 2. Merging will resume Tuesday. Authors can still review and sign off on PRs in the interim. Thanks.


DataVariable.code_refs does not match bv.get_code_refs(DataVariable.address)

On BinaryNinja v1.1.1555 (latest stable as of this writing)
>>> bv.get_code_refs(bv.get_data_var_at(0x80560e0).address)
[<ref: x86@0x8052ab5>, <ref: x86@0x8048f85>, <ref: x86@0x8048f8b>, <ref: x86@0x80529dd>, <ref: x86@0x8052a3d>, <ref: x86@0x8052a0d>, <ref: x86@0x8052959>, <ref: x86@0x805296f>, <ref: x86@0x8052975>, <ref: x86@0x805299f>, <ref: x86@0x8052a6d>]

>>> bv.get_data_var_at(0x80560e0).code_refs
[]

fsck.tar.gz

Ahh, I'm not sure which fix improved this, but this is actually fixed on the latest dev, that's why I was unable to repro it. Simple update to the latest dev branch in your preferences and this should no longer be an issue.


tokein is not ready(revoked or expired) error

void init_Firebase()
{
/* Assign the api key (required) /
config.api_key = API_KEY;
/ Assign the user sign in credentials /
auth.user.email = USER_EMAIL;
auth.user.password = USER_PASSWORD;
/ Assign the RTDB URL */
config.database_url = DATABASE_URL;
// required for legacy HTTP API
Firebase.FCM.setServerKey(FIREBASE_FCM_SERVER_KEY);
fbdo.setResponseSize(2048);
String base_path = "/default/";
/* Assign the callback function for the long running token generation task /
config.token_status_callback = tokenStatusCallback; // see addons/TokenHelper.h
/ Initialize the library with the Firebase authen and config */
Firebase.begin(&config, &auth);
Firebase.reconnectWiFi(true);
if(Firebase.RTDB.setQueryIndex(&fbdo, "/default/" /* parent path of child's node that is being queried /, "" / the child node key that is being queried */, DATABASE_SECRET))
{
_printf("Firebase is OK\n");
}
else
{
1) error
_printf("error = %s\n", fbdo.errorReason().c_str());
}
QueryFilter query;
query.limitToLast(8);
String s = "";
if (Firebase.RTDB.getJSON(&fbdo, "/default", &query))
{
// printResult(fbdo.jsonString()); // see addons/RTDBHelper.h
s = fbdo.jsonString();
}
_printf("firebase result = %s\n", s);
// Clear all query parameters
query.clear();
StaticJsonDocument doc;
DeserializationError error = deserializeJson(doc, s);
if (error)
{
2) error
_printf("deserializeJson() failed:  %s\n", error.c_str());
}
String s1 = doc["mqtt_uri"];
String s2 = doc["firmware"]["mopeka"]["version"];
String szFBURI = doc["firmware"]["mopeka"]["path"];
_printf("mqtt_url = %s,  szFBVersion = %s, url = %s\n", s1.c_str(), s2.c_str(), szFBURI.c_str());
if (s1.equals("null"))
{
s1 = "ucore.iptime.org";
}
if (s2.equals("null"))
{
s2 = "7";
}
if (szFBURI.equals("null"))
{
szFBURI = "firmware/mopeka/firmware.bin";
}
network.szMqttServer = s1;
eprom.writeStringToFlash(s1.c_str(), ER_MQTTSERVER);
doc.clear();
}
IDE and its version:

Arduino, PlatformIO
Version [e.g. 1.8.9]

; platform = espressif32 ;https://github.com/tasmota/platform-espressif32/releases/download/v2.0.3rc1/platform-espressif32-2.0.3new.zip
platform = https://github.com/tasmota/platform-espressif32/releases/download/v2.0.3rc1/platform-espressif32-2.0.3new.zip
platform_packages = framework-arduinoespressif32 @ https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/829/framework-arduinoespressif32-v4.4.1-3010c4571f.tar.gz
board = esp32-s3-devkitc-1
framework = arduino
board_build.mcu = esp32
;upload_speed = 921600
;upload_port = COM10
monitor_speed = 115200
board_upload.flash_size = 8MB
board_build.partitions=default_8MB.csv
build_flags =
-O2
-ffunction-sections
-fdata-sections
-Wl,--gc-sections
lib_deps =
<EMAIL_ADDRESS><EMAIL_ADDRESS>adafruit/Adafruit<EMAIL_ADDRESS>mobizt/Firebase Arduino Client Library for ESP8266 and<EMAIL_ADDRESS>pio error message log

error = token is not ready (revoked or expired)
deserializeJson() failed:  EmptyInput

This is a source that retrieves data using Firebase's realtime database and connects to the MQTT server.
This is the source code that has been widely used in the meantime.
But at some point it didn't work.
The error is that token is not ready, but the DB access permission is set to true.
I searched for the same phenomenon for several days and tried entering admin tokens, but the error is the same.
Is it because Firebase's policy changed? I am leaving a message because I cannot solve the problem on my own.

You should follow the library examples for correct usage.
https://github.com/mobizt/Firebase-ESP-Client/blob/f17ea76ae870d6e02290504b1bd7e9599a3ca5cb/examples/RTDB/Basic/Basic.ino#L176-L181

/**

Created by K. Suwatchai (Mobizt)

Email<EMAIL_ADDRESS>
Github: https://github.com/mobizt/FirebaseJson

Copyright (c) 2023 mobizt

*/
#include <Arduino.h>
#if defined(ESP32) || defined(ARDUINO_RASPBERRY_PI_PICO_W)
#include <WiFi.h>
#elif defined(ESP8266)
#include <ESP8266WiFi.h>
#endif
#include <Firebase_ESP_Client.h>
// Provide the token generation process info.
#include <addons/TokenHelper.h>
// Provide the RTDB payload printing info and other helper functions.
#include <addons/RTDBHelper.h>
/* 1. Define the WiFi credentials /
#define WIFI_SSID ""
#define WIFI_PASSWORD "*"
// For the following credentials, see examples/Authentications/SignInAsUser/EmailPassword/EmailPassword.ino
/* 2. Define the API Key /
#define API_KEY "AIz*****H2jXuB24bQwjfw"
/* 3. Define the RTDB URL /
#define DATABASE_URL "https://sma*****t-rtdb.firebaseio.com" //.firebaseio.com or ..firebasedatabase.app
/* 4. Define the user Email and password that alreadey registerd or added in your project /
#define USER_EMAIL ""
#define USER_PASSWORD "*"
// Define Firebase Data object
FirebaseData fbdo;
FirebaseAuth auth;
FirebaseConfig config;
unsigned long sendDataPrevMillis = 0;
unsigned long count = 0;
void setup()
{
Serial.begin(115200);

WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
Serial.print("Connecting to Wi-Fi");
while (WiFi.status() != WL_CONNECTED)
{
    Serial.print(".");
    delay(300);
}
Serial.println();
Serial.print("Connected with IP: ");
Serial.println(WiFi.localIP());
Serial.println();

Serial.printf("Firebase Client v%s\n\n", FIREBASE_CLIENT_VERSION);

/* Assign the api key (required) */
config.api_key = API_KEY;

/* Assign the user sign in credentials */
auth.user.email = USER_EMAIL;
auth.user.password = USER_PASSWORD;

/* Assign the RTDB URL (required) */
config.database_url = DATABASE_URL;

/* Assign the callback function for the long running token generation task */
config.token_status_callback = tokenStatusCallback; // see addons/TokenHelper.h

// Since Firebase v4.4.x, BearSSL engine was used, the SSL buffer need to be set.
// Large data transmission may require larger RX buffer, otherwise connection issue or data read time out can be occurred.
fbdo.setBSSLBufferSize(2048 /* Rx buffer size in bytes from 512 - 16384 */, 1024 /* Tx buffer size in bytes from 512 - 16384 */);

// Or use legacy authenticate method
// config.database_url = DATABASE_URL;
// config.signer.tokens.legacy_token = "<database secret>";

Firebase.begin(&config, &auth);

// Comment or pass false value when WiFi reconnection will control by your code or third party library e.g. WiFiManager
Firebase.reconnectNetwork(true);

}
void loop()
{
// Flash string (PROGMEM and  (FPSTR), String C/C++ string, const char, char array, string literal are supported
// in all Firebase and FirebaseJson functions, unless F() macro is not supported.
// Firebase.ready() should be called repeatedly to handle authentication tasks.

if (Firebase.ready() && (millis() - sendDataPrevMillis > 15000 || sendDataPrevMillis == 0))
{
    sendDataPrevMillis = millis();

    FirebaseJson json;
    json.setDoubleDigits(3);
    json.add("value", count);

    Serial.printf("Set json... %s\n", Firebase.RTDB.setJSON(&fbdo, "/test/json", &json) ? "ok" : fbdo.errorReason().c_str());

    Serial.printf("Get json... %s\n", Firebase.RTDB.getJSON(&fbdo, "/test/json") ? fbdo.to<FirebaseJson>().raw() : fbdo.errorReason().c_str());

    FirebaseJson jVal;
    Serial.printf("Get json ref... %s\n", Firebase.RTDB.getJSON(&fbdo, "/test/json", &jVal) ? jVal.raw() : fbdo.errorReason().c_str());

    FirebaseJsonArray arr;
    arr.setFloatDigits(2);
    arr.setDoubleDigits(4);
    arr.add("a", "b", "c", true, 45, (float)6.1432,<PHONE_NUMBER>9);

    Serial.printf("Set array... %s\n", Firebase.RTDB.setArray(&fbdo, "/test/array", &arr) ? "ok" : fbdo.errorReason().c_str());

    Serial.printf("Get array... %s\n", Firebase.RTDB.getArray(&fbdo, "/test/array") ? fbdo.to<FirebaseJsonArray>().raw() : fbdo.errorReason().c_str());

    Serial.printf("Push json... %s\n", Firebase.RTDB.pushJSON(&fbdo, "/test/push", &json) ? "ok" : fbdo.errorReason().c_str());

    // json.set("value", count + 0.29745);
    // Serial.printf("Update json... %s\n\n", Firebase.RTDB.updateNode(&fbdo, "/test/push/" + fbdo.pushName(), &json) ? "ok" : fbdo.errorReason().c_str());

    count++;
}

}
Even though I just copied and pasted the example provided in the sample. The error details are the same.
The rules of Firebase's realtime database are .read: true, .write: "auth.uid != null".
I've been suffering from the same error for several days.
console  log
Connecting to Wi-Fi....
Connected with IP: <IP_ADDRESS>
Firebase Client v4.4.11
Token info: type = id token (GITKit token), status = on request
Token info: type = id token (GITKit token), status = ready
Set json... token is not ready (revoked or expired)
Get json... token is not ready (revoked or expired)
Get json ref... token is not ready (revoked or expired)
Set array... token is not ready (revoked or expired)
Get array... token is not ready (revoked or expired)
Push json... token is not ready (revoked or expired)

The problem is on your side which you should be solved.
The library works normally and test 24/7 for years.
You should try with clean library installation and new Firebase project.

Hello @thinkupplus,
Have you ever figured this out?
Interestingly I can set but can not get
14:54:26.000 -> Token info: type = id token (GITKit token), status = on request
14:54:27.242 -> Token info: type = id token (GITKit token), status = ready
14:54:29.336 -> Set Wifi connected success
14:54:29.602 -> Set epoch success
14:54:30.630 -> Get int... token is not ready (revoked or expired)
I made sure that the database rules are not the reason

@ateker01
If the time was changed or set after authenticated, you have to call Firebse.begin again to re-authenticate.

Hello @thinkupplus, Have you ever figured this out? Interestingly I can set but can not get
14:54:26.000 -> Token info: type = id token (GITKit token), status = on request 14:54:27.242 -> Token info: type = id token (GITKit token), status = ready 14:54:29.336 -> Set Wifi connected success 14:54:29.602 -> Set epoch success 14:54:30.630 -> Get int... token is not ready (revoked or expired)
I made sure that the database rules are not the reason

I haven't solved this problem yet

I had actually have multiple issue and I looked at a little deeper after @mobizt's comment.
I was calling the firebase authentication too often. Once I removed that, the token failure stopped.

@thinkupplus
You should try to use the latest sdk and platform by ignoring these specific.
platform = https://github.com/tasmota/platform-espressif32/releases/download/v2.0.3rc1/platform-espressif32-2.0.3new.zip
platform_packages = framework-arduinoespressif32 @ https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/829/framework-arduinoespressif32-v4.4.1-3010c4571f.tar.gz

It should be ok if you use the mainstream platform and packages.


Fixed bundle type equality.

Was not checking for length of bundles, so if the bundles matched but one had more fields, it was not caught. #89

Merged in f93dc6831e282338bcda1db04dbf272a36b4a895


[Bug]: After Update to iOS 16.4 (Beta) no HomeKit Device found

What happened?
After updating my iOS devices (iPhone + Apple TV) to iOS 16.4 (Beta) to improve HomeKit performance & possibly fix some issues, an Eufy Cam in HomeKit has now completely disappeared.
The Euyf plugin runs on the PI as a standalone bridge. After the reboot, the cam was still gone. Even after completely re-setting up the plugin & adding the eufy homebrige to HomeKit, only the bridge was displayed, but no compatible iOS device that I could assign to a room.
Seems like iOS 16.4 is now turning off some Homebridge plugins so they don't work in HomeKit anymore.
Would be great if this could be fixed with one of the upcoming plugin updates.
thanx,
Alex
Device Type
Indoor Camera (Supported)
Plugin Version
v2.0.x (Supported)
HomeBridge Version
v1.4.x (Supported)
NodeJS Version
v16 (Supported)
Operating System
Raspbian 10+ (Supported)
Relevant log output
No error visible in the log

config
.

Hello,
Thank you for your comment.
Indeed, I checked all other rooms, nowhere was a Device to be found. The camera was not shown to me either.
I have now several times reseted the plugin and & set up again, always as a separate bridge with different software versions.
After what felt like 20 attempts now finally the success. The camera is back online and now runs with the plugin version 2.1.4.
iOS 16.2 had already triggered the switch to the new HomeKit architecture, but after that everything ran normally.
No idea what the problem was in the end, but I'm happy that the camera is now integrated again via Homebridge.

Closed


[Fix uwp toolchain|world rebuild] make ninja work for uwp

depends #23001
depends #23846 (for less changes)
closes #19601

This may fix #19818.

This may fix #19818.

be aware that the Fortran runtime libraries are not build against WindowsApp.lib which makes them not suiteable for UWP. So currently, Fortran cannot support UWP.

@BillyONeal: Please take a look at the uwp errors (except boost) and tell me which class of errors should be marked as supports: "!uwp"

Unfortunately I know next to nothing about UWP; although if things built in the old msbuild world order it doesn't seem like a "shared" change like this should change which things are built successfully?

built in the old msbuild

As far as i know normal CI won't tell me if i passed a former regression and subsequent ports now fail.
Also cmake msbuild != vs default msbuild. Cmake is probably just using /ZW which is why it works. I'll compare some cmake msbuild build flags against this PR. Currently this PR uses just the vs defaults.

Since https://github.com/microsoft/vcpkg-tool/pull/350 was merged, can we continue this PR?

still depends on https://github.com/microsoft/vcpkg/pull/23001 to move on.

@JackBoosY Found the error: The ports failing are all using MSBuild since PREFER_NINJA is missing. For some reason CMake + VS Generator chokes on /WINMD in the  CMAKE_EXE_LINKER_FLAGS. I also observed that the compiler check is not correctly using the /FU flag (containing and ugly space) so i had to move it into the environment variable.

REGRESSION: physfs:arm-uwp # CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately:    HAS_PRE_1970_EXITCODE (advanced)   HAS_PRE_1970_EXITCODE__TRYRUN_OUTPUT (advanced)
REGRESSION: orc:arm-uwp # D:\buildtrees\physfs\src\3.0.2-5516c52307.clean\src\physfs_platform_winrt.cpp(29): error C2653: 'Windows': is not a class or namespace name
REGRESSION: physx:arm-uwp # D:\buildtrees\physx\src\be49a99479-2db4990732.clean\pxshared\include\foundation/PxPreprocessor.h(449): fatal error C1189: #error:  Exactly one of NDEBUG and _DEBUG needs to be defined!

so physfs is not setup for cross builds -> probably ci baseline it
orc seems to have simple syntax errors (maybe missing include) -> upstream issue -> ci baseline?
physx needs /DNDEBUG in release builds -> fix by adding /DNDEBUG to the toolchains _RELEASE compiler flags

Yeah uwp is green

Errors occurred while parsing C:\a\1\s\ports\igraph\vcpkg.json
    $.port-version: mismatched type: expected a nonnegative integer

So I think my PR https://github.com/microsoft/vcpkg/pull/21537 can be closed?

So I think my PR https://github.com/microsoft/vcpkg/pull/21537 can be closed?

Probably ;).

I mean I love the idea, but I'm definitely not an expert; you'll have to poke Robert to get a review

cc @ras0219-msft

Thanks for making this work @Neumann-A : Words can't describe how much I appreciate the pain you went through to get here trying to demystify the UWP black box. I'm going to try to confirm with some folks who own what UWP means tomorrow.

@JackBoosY I'm waiting for internal folks to OK it, @Neumann-A doesn't need to respond unless they want. :)

Thanks again for getting UWP to not be a special snowflake!


Deposit using the sdr-api account of the depositor (rather than the h2 account)

we cannot give users a token to deposit directly to sdr-api, because sdr-api allows you to deposit into multiple collections, which is something we don't allow in h2.


RHTAPBUGS-118: fix link and product name

This PR fixes a link from RHTAPBUGS-118 and also removes an outdated product name as was requested on Slack: forum-hac-docs.
Will appreciate your review @Hyperkid123, thank you.

/ok-to-test


FEATURE REQUEST: A way to save the scan after every permutation tested

It would be great to be able to save the scan to a file after every premutation to be able to continue where it left of if it was interupted for some reason. Right now if I have a long running scan process and the computer shuts down I have to redo everything. If we could save and continue scans this would allow backing up the partial results and avoid loosing as much work.

I agree, this is a key feature to add. IMO the single most important entirely new feature to add. It will be straightforward to do this with the building blocks that are already there (I think). I will work on this and it will be included in the v.0.5 which should be a few weeks away.

I would like to make a suggestion for this. I'm not sure if you would consider this a different feature, but it might be at least a quick temporary fix.

Scan() creates a directory talos_output
For each experiment, Talos creates a subdirectory, named after the ID of the experiment (the row number in the .csv file)
Scan() adds the path to the experiment's output directory to the params dict before passing it to the model function.
The model function can now save everything to this directory, and it is clear which experiment the output belongs to.

Would this be feasible?

I think that does make sense.
Regarding the specific case that @JohanMollevik is suggesting, given we already store the log with information on each permutation, we would have to decide what else is a must have in the folder. Maybe start by storing the weights and json for each model, as together with the results that should be enough to not lose anything substantial even though there was a system crash or something like that. That part would have to be an argument in Scan() though, maybe model_backups=True.

I think it might also be nice to have some plots of the history during training, and perhaps some explanation plots (SHAP? Lime?)
But most important for reproducible runs is the state of the used RNGs. That should be logged definitely.

I think it might also be nice to have some plots of the history during training (of all metrics & the loss)

This is now available with ExperimentLogCallback

More updates regarding this:

Scan(...experiment_name...) is now required for all experiments
in the present working directly, folder with that name will be created
inside that folder the experiment log is stored with .csv ending using second precision timestamp
if using ExperimentLogCallback one must use the same experiment_name there as input
ExperimentLogCallback will do matching for the actual file name based on the most recently modified file in that folder, which should be the experiment log
experiment log with permutation data has .csv ending and epoch-by-epoch log has .log ending

This should be pushed later today.

Update
From 0.6.3 onwards, there is available Scan(...reduction_method='gamify) which outputs to the experiment folder with the experiment id a .json file during each permutation. In that file there is a dictionary with dictionaries, where the main dictionary keys consist of hyperparameter labels, and the sub-dictionaries consist of hyperparameter values corresponding to the label (e.g. lr and 0.01). Together with the value there is a string 'active' by default. Changing this to 'inactive' in the local file, during the next permutation all permutations in the parameter space with that value will be dropped.
Related with this, as of yesterday a visual command center (well for now it's just the visuals, but commands are coming). It's called Gamify and it allows you to visualize and analyze the experiment results during the experiment through a web browser.

With the Talos v.0.6.3 changes, also controls will be added to Gamify, so that you can analyze the results, make changes, and see the changes for yourself in real-time. Gamify has live monitoring for epoch-by-epoch data as well.


String interpolation not working

While using Winston in my application, none of the string interpolations seem to be working:
config = { name: "local", identity: "https://localhost:844" };
env_name = "local";

var logger = require('winston');
logger.log("info", "Starting up with config %j", config);
logger.log("info", "Env is %s", env_name);

prints out
info: Starting up with config %j name=local, identity=https://localhost:844
info: Env is %s local

I'm using 1.0.0

Winston uses the last object passed to log as metadata, so you'll need to provide a blank object for your logs to work as you intend:
logger.log("info", "Starting up with config %j", config, {});

Results in:
info: Starting up with config {"test":"property"}

This continually trips me up :\
As for your second statement, if env_name is a string, there's no need to interpolate it, you can just include it and it will be printed out console.log style. logger.log("info", "Env is", env_name);
All together:
 logger.log("info", "Starting up with config %j", config, {});
 logger.log("info", "Env is", env_name);

info: Starting up with config {"test":"property"}
info: Env is foo

That was it, thanks!


Using -enableRule:AppOffline stops msdeploy from creating the folder on disk

WinRM - IIS Web App Deployment
If you're deploying a new site, and the physical folder doesn't exist then msdeploy will create that folder for you and deploy the site into it.
However if you use -enableRule:AppOffline then you get this error
Error: Could not find a part of the path 'C:\inetpub\wwwroot\MyProjectName\App_Offline.htm'
My RM deployment will create an environment and site if none exists, otherwise it updates the existing. This makes it tricky to have a single script that does it all. As a workaround I've had to add a powershell task to create the folder if required.

Thanks for reporting we will address this

We have fixed this, we are creating folder upfront so this should happen


Added theme lush-green

Hey, this looks amazing! Thanks for the contribution

Can you check if its fixed?

Looks good, I'll merge this if you don't have any pending changes

Yes its done. Thank you


On PyPy test_random_data_multidim_axes crashing

The CircleCI PyPy run result (example):
[gw1] linux -- Python 3.5.3 /usr/local/bin/pypy3
Worker 'gw1' crashed while running 'build/testenv/site-packages/scipy/signal/tests
/test_signaltools.py::TestFFTConvolve::test_random_data_multidim_axes[axes4]'

The test:
    @pytest.mark.parametrize('axes', [[1, 4],
                                      [4, 1],
                                      [1, -1],
                                      [-1, 1],
                                      [-4, 4],
                                      [4, -4],
                                      [-4, -1],
                                      [-1, -4]])
    def test_random_data_multidim_axes(self, axes):
        np.random.seed(1234)
        a = np.random.rand(123, 222) + 1j * np.random.rand(123, 222)
        b = np.random.rand(132, 111) + 1j * np.random.rand(132, 111)
        expected = convolve2d(a, b, 'full')

        a = a[:, :, None, None, None]
        b = b[:, :, None, None, None]
        expected = expected[:, :, None, None, None]

        a = np.rollaxis(a.swapaxes(0, 2), 1, 5)
        b = np.rollaxis(b.swapaxes(0, 2), 1, 5)
        expected = np.rollaxis(expected.swapaxes(0, 2), 1, 5)

        # use 1 for dimension 2 in a and 3 in b to test broadcasting
        a = np.tile(a, [2, 1, 3, 1, 1])
        b = np.tile(b, [2, 1, 1, 4, 1])
        expected = np.tile(expected, [2, 1, 3, 4, 1])

        out = fftconvolve(a, b, 'full', axes=axes)
        assert_(np.allclose(out, expected, rtol=1e-10))

As much as I would love to keep the PyPy run, I think this is a bit too much for us to maintain. Seemingly random fails are quite common from again random places (of course there is an underlying reason probably somewhere).

Xref #9508

We added pypy3 ourselves to CI in gh-8783, under the assumption that it would not be much work. These failures do seem consistent, I get the same ones repeatedly (CircleCI sends nice "build failed" emails post-merge). So points towards real bugs in PyPy, perhaps in combination with changes in NumPy that now trigger the crashes.
@mattip how would you suggest to deal with these? Report to PyPy and skip perhaps?

Ah what I meant by random is that when we fix one, another fail pops up but not simultaneously.

Ah yes, because of the crashes - hard to tell how many are left for tests that are now never executed. That would require someone to reproduce these locally, indeed not much point skipping tests one by one.

Runnine the circleCI pypy3 test setup locally does not crash on my Ubuntu 18.04, even when running with -n4. Did the CI check once run successfully and suddenly stop doing so? Perhaps the circleci is using a different BLAS than mine which has some issues with threading, and PyPy hits that issue more consistently?

The SciPy build uses ATLAS (https://github.com/scipy/scipy/blob/master/.circleci/config.yml#L110) while NumPy is installed from a wheel so should be using OpenBLAS. I suspect OpenBLAS will be the issue. I'll have a look at the history, maybe there's a correlation with OpenBLAS version.

Okay, the original PR was pre numpy 1.15.0, and used numpy master because there were some pypy3 fixes in there that were needed. Then we switched to >=1.15.0, so it means we switched from a numpy source build which would have picked up ATLAS to now 1.15.4 which uses OpenBLAS 0.3.0.
@mattip why do you specifically say "issues with threading"?

It seems OpenBlas is not really thread safe, there are various open issues around it in NumPy. PyPy may be more aggressively or even improperly releasing the GIL in its C-API compatibility layer. Could we run the CI with whatever environment variable signals to BLAS to run single threaded, or will that make it run too slow?

Assuming my leap of faith is correct and threading is the issue, and not some GC related kerfuffel. Strange it doesn't show up locally, even when following the CI recipe.

Failures still occurring: https://circleci.com/gh/scipy/scipy/10272?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification. It seems non-deterministic. Still have the impression that OPENBLAS_NUM_THREADS=1 helped, but didn't fix it all.

This is definitely still crashing in a number of recent PRs.

It might be a OOM crash caused by the 4GB machine limit when running pytest -n3. When I set ulimit -m 990 and run the tests in a single instance (without the -n3), I can reproduce the crash. Setting PYPY_GC_MAX=900MB to force the GC to be more aggresive about collecting memory seems to solve it locally. I am still investigating the root cause, but would it be acceptable to add that environment variable, and remove the OPENBLAS_NUM_THREADS=1?

that sounds fine to me


chore(deps): update dependency @types/react to v16.9.2

This PR contains the following updates:

Package
Type
Update
Change

@types/react
devDependencies
patch
16.9.1 -> 16.9.2

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Enabled.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

PR has been edited
:construction_worker: This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over you may click the "rebase" checkbox in the PR body/description.


Enhancement: Fix week7

I fix about week7 on fnf newground port and i turn it into og engine https://github.com/Sanscode1937/OG-ENGINE
I will credit to you soon

I'll compile it and run this on my machine and I'll see if it will possibly work

Not trying to be rude, but have you played the Newgrounds version? You've stripped away options, removing custom inputs, removed the Change Difficulty, and Practice Mode you also broke the blueballed counter, also what do you mean by "fixed week 7" there doesn't seem to be anything wrong with it in the build Angel made.


grpcio: split outputs to remove build protobuf from closure

Motivation for this change
The Python protobuf library has C++ protobuf in propagatedNativeBuildInputs. When cross-compiling this causes a build arch package to end up in grpcio's runtime closure, which can be be prevented by splitting outputs.
cc @marsam @matthewbauer
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@ofborg build python3Packages.grpcio python3Packages.grpcio-tools pkgsCross.aarch64-multiplatform.python3Packages.grpcio pkgsCross.aarch64-multiplatform.python3Packages.grpcio-tools


added http get header support

Codecov Report

Merging #1 (f909fc6) into master (36fa8ce) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master        #1   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           19        22    +3
=========================================
+ Hits            19        22    +3

Impacted Files
Coverage Δ

client.go
100.00% <100.00%> (ø)

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 36fa8ce...f909fc6. Read the comment docs.


PUT does not work in REPL mode using some kinds of JSON

Because of the way arguments are parsed, any JSON value that includes a space, will result in an error. For example:
put testkey "{\"test\":\"some value\"}"
will fail because the value will be interpreted as {"test":"some
The error is cause by the argument handling here:
https://github.com/0x00A/lev/blob/cff7f20484a1247a3d08aadeb42b8e7088ff2b94/lib/repl.js#L66

Seems like your PR should address this, so could this be closed?


feat(core): added events module

@Snazzah The idea is to listen for events from any emitter, not just the ones the client emits.
From what I understood the EventRegistry only listens for events from the client


Correct typo about RFC 3709

Correct typo about RFC 3709 in CHANGES.txt and the comments in rfc3709.py

This PR includes too many unrelated commits. I had to cherry-pick from it so the fix is in master by now.
Thank you!


Prepare remote schedulerService for YuniKorn PR

Create PR on YuniKorn Web for the schedulerService (remote component) that is loaded from YHS

YUNIKORN-2949

PR: https://github.com/apache/yunikorn-web/pull/217


Preserve mtime of files when preserve_mtime flag is set

Similar to #155, we need to have our content files served with a timestamp representing when they were last modified or built.

This has be a distinct flag.   In #155 we determined that preserve mtimes of files in included tarballs. will not break repeatable builts.  Using the mtime of files has reproducibility problems.

My first path of action and still my preference would be to make this able to use the build stamp vars and the mtime arg, but I found that there wasn't really a straightforward way to get those in the bazel API for .bzl files without parsing out the stamp files myself. Perhaps I just didn't look in the right place. Also, the current usage of the mtime arg is only applied to the overall tar file's time, not the files inside.

That is certainly different than what this PR does.  What if there was a magical syntax like  mtime = "VOLATILE_BUILD_TIME"?
This would make the target non-reproducible, because every time you build you would get a new result. OTOH, that might be what you want.

That is certainly different than what this PR does. What if there was a magical syntax like mtime = "VOLATILE_BUILD_TIME"?

Isn't that one of the purposes for the existing build stamping in Bazel, e.g. with BUILD_TIMESTAMP?

This would make the target non-reproducible, because every time you build you would get a new result. OTOH, that might be what you want.

Reproducible in the exact down to the byte form is not required. The main thing needed is for the files served via http from the new image should be the same or newer timestamps compared to the previously built and deployed image so the last-modified and etag headers are useful.


CNI config in README out of date

The README does not reflect the CNI config of this plugin. it should be updated so users understand what is an acceptable configuration

fixed by #21


Fix mew module title paddings and margins

@hsurf22 should we just completely remove the title paddings? is there anywhere we will need it? I remember me n olga were playing around with it and added it to see

@hsurf22 should we just completely remove the title paddings? is there anywhere we will need it? I remember me n olga were playing around with it and added it to see

Sure why not. Let me remove the paddings and resubmit the PR.


feat: separate health check api for redis and mongo (#19425)

Cherry picking health check API endpoint to be used to readiness and liveness probes in kubernetes.

/ok-to-test sha=27d455e

Decided not to cherry pick the health check probe. This change would be available through the normal release cycle in the next promotion. Related conversation here.


Linux build version script to hide exports of dependencies

Description of Change
Currently symbols of Freetype etc. are exported during the linker process. This leads to errors when used with applications that load build in third party libraries.
Bugs Fixed

Related to issue #927

I see an error:

/usr/bin/ld:/__w/1/s/native-builds/libSkiaSharp_linux/libSkiaSharp.map:7: syntax error in VERSION script

Let me fire up a VM quick

I think it was missing the last semicolon... Let's see.

Do you use a VM of WSL?

Seems to have passed the build of libSkiaSharp for Linux.

Y same on my machine. Looks okay now.

I wonder why Fontconfig is still exported. There seems to be a version script for glibc as well.


#2110 - Add to search price range min - max

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[ ] Bugfix
[x] Feature
[ ] Refactoring

What's new?

[x] PR closes #2110
[ ] added requested range slider emmiting events on movement of both handles. currently not affecting search, as I couldn't figure out connection to graphql query (subquery based on @vikiival query added to folder with queries under nftPriceRange.graphql)

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[x] I've posted a screenshot of demonstrated change in this PR

Optional

[x] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[x] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[ ] Fill up your KSM address: Payout -> whoever fixes this, feel free to add your address.

Community participation

[x] Are you at KodaDot Discord?

Screenshot

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

https://user-images.githubusercontent.com/73316633/153254542-4400fe24-6246-4e2e-a7fe-a6ded2e6b8cb.mp4

From a UI aspect, I would put the slider in the collapse filter and reduce the size

you're right, I think whole search area needs some upgrade when it comes to UI. I'd like to solve that here https://github.com/kodadot/nft-gallery/issues/2261. Changed it to this version for now:

how does it work? Do I need to press something extra?

Note: I would hide the slider if "BUY NOW" button isn't toggle ON

Note: I would hide the slider if "BUY NOW" button isn't toggle ON

legit

Still stucked with the query @petersopko ?

should be working now, I'm gonna polish, test edge cases and refine a little tomorrow

Let's resolve merge conflicits, so we can test it :)

Yeah I would opt out for now for default. As price filter is something people would explicitly turn on.
Mind check Airbnb as example, doesn't automatically suggest you looking for 1k/night places )

Mind check Airbnb as example, doesn't automatically suggest you looking for 1k/night places )

Airbnb's initial search is this:
Is that what you meant? Should I turn the last tick of the search to 30+ instead of fix 30? And have the default set for fully open slider ? (0-30+)

I was pointing out that they don't enable it until you explicitly click on it tho :)
When I make my initial search
https://www.airbnb.com/s/Slovenia/homes?
tab_id=home_tab&refinement_paths%5B%5D=%2Fhomes&flexible_trip_dates%5B%5D=february
&flexible_trip_dates%5B%5D=march&flexible_trip_lengths%5B%5D=weekend_trip
&date_picker_type=calendar&query=Slovenia
&place_id=ChIJYYOWXuckZUcRZdTiJR5FQOc
&checkin=2022-03-14&checkout=2022-03-18&adults=2&source=structured_search_input_header&search_type=autocomplete_click

When I clicked save, it added URL param, hint is last
https://www.airbnb.com/s/Slovenia/homes?tab_id=home_tab&refinement_paths%5B%5D=%2Fhomes&flexible_trip_dates%5B%5D=february
&flexible_trip_dates%5B%5D=march&flexible_trip_lengths%5B%5D=weekend_trip
&date_picker_type=calendar&query=Slovenia&place_id=ChIJYYOWXuckZUcRZdTiJR5FQOc
&checkin=2022-03-14&checkout=2022-03-18&adults=2&source=structured_search_input_header&search_type=filter_change
&price_min=42&price_max=420

okay from UI perspective, right now don't see what's I'm looking at when I fold filter and can't share my search with others.
Suggestions

maybe next to search bar add what's current range? It's fairly enough state like 0-11KSM, or <11KSM if there is begging by zero, hint from airbnb, pic1
add params to url, price_min=0&price_max=11 sounds good to me

https://user-images.githubusercontent.com/5887929/154035203-310cbbf6-f23b-46df-901f-21ec8fb9ee49.mov

add params to url, price_min=0&price_max=11 sounds good to me
or just min&max ?

While testing for edge cases I found out that "Buy Now" toggle is working well in one way, i.e. to select for prices greater than 0. Doesn't work the other way around, "unlisted" option also shows listed NFTs just without price (this is the case for production as well, not just this branch). Couldn't find solution right away.
I added requested changes, kept the "price range info" style simple in the style of the above search info.

bruh

pay 200 usd

Fill up your KSM address: Payout -> whoever fixes this, feel free to add your address.

Oh this is cute! :)

bruh

will do next time, sorry


Failing floating-point multiplication

x = APyFloat(sign=0, exp=0, man=11, exp_bits=4, man_bits=20)
y = APyFloat(sign=0, exp=5, man=50, exp_bits=16, man_bits=50)
x * y

currently returns oo, but should be 0.

I think a reason may be that normalized is not correct as sometimes more than one additional exponent bits is required. In this case the resulting exponent in x.normalized() becomes negative, so it ends up to be a gigantic positive number.

I took a quick look at this, and I think you are correct.


Import remaining out-of-sync config

https://github.com/alphagov/rubocop-govuk/issues/73
Please see the commits for more details.

@kevindew yeah, I'm aware some of the DB-related Cops aren't very clever sometimes. I'll watch out for that.
I'm going to leave #99 out of this release, to keep it more manageable - once all the repos are in sync, we can think about what an update strategy for this repo should look like.


Rerun agents

rerun all notebooks in the folder
Save their results
Commit to your fork
raise a PR from your fork to the main repo's staging branch

Added the variable "os.environ['API_KEY'] = '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'"

Created a .env file for the api key


fix(dep): dependbot yml updated

workflow yml updated

:tada: This PR is included in version 1.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


nodePackages: update to latest

Description of changes
updating node-packages to latest because I want to add maizzle
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 234332 run on x86_64-linux 1

29 packages failed to build:

python310Packages.batchspawner
python310Packages.batchspawner.dist
python310Packages.dockerspawner
python310Packages.dockerspawner.dist
python310Packages.jupyterhub
python310Packages.jupyterhub-ldapauthenticator
python310Packages.jupyterhub-ldapauthenticator.dist
python310Packages.jupyterhub-systemdspawner
python310Packages.jupyterhub-systemdspawner.dist
python310Packages.jupyterhub-tmpauthenticator
python310Packages.jupyterhub-tmpauthenticator.dist
python310Packages.jupyterhub.dist
python310Packages.oauthenticator
python310Packages.oauthenticator.dist
python311Packages.batchspawner
python311Packages.batchspawner.dist
python311Packages.dockerspawner
python311Packages.dockerspawner.dist
python311Packages.jupyterhub
python311Packages.jupyterhub-ldapauthenticator
python311Packages.jupyterhub-ldapauthenticator.dist
python311Packages.jupyterhub-systemdspawner
python311Packages.jupyterhub-systemdspawner.dist
python311Packages.jupyterhub-tmpauthenticator
python311Packages.jupyterhub-tmpauthenticator.dist
python311Packages.jupyterhub.dist
python311Packages.oauthenticator
python311Packages.oauthenticator.dist
thelounge

46 packages built:

balanceofsatoshis
bitwarden-cli
castnow
commitlint
concurrently
create-cycle-app
emacsPackages.lsp-bridge
emanote
emanote.data
fast-cli
flexoptix-app
gtop
joplin
lighthouse
lv_img_conv
morgen
openmoji-black
openmoji-color
pm2
postcss-cli
pulsar
pyright
redoc-cli
slack
teams
theLoungePlugins.plugins.closepms
theLoungePlugins.plugins.giphy
theLoungePlugins.themes.abyss
theLoungePlugins.themes.flat-blue
theLoungePlugins.themes.flat-dark
uppy-companion
vimPlugins.coc-metals
vimPlugins.coc-pyright
vimPlugins.coc-stylelint
vimPlugins.markdown-preview-nvim
vscode
vscode-extensions.ms-python.vscode-pylance
vscode-extensions.rust-lang.rust-analyzer
vscode-fhs
vscode-with-extensions
vscodium
vscodium-fhs
wasm-text-gen
wrangler
yaml-language-server
zx

@ixxie @cstrahan  this update seems to bring a jupyterhub failure causing the downstream failures.
In this PR I've just run the nodePackages update generator.sh, It looks like related to an update of configurable-http-proxy maybe ?
Does the jupyterhub need to be updated ?

Result of nixpkgs-review pr 234332 run on x86_64-linux 1

28 packages failed to build:

python310Packages.batchspawner
python310Packages.batchspawner.dist
python310Packages.dockerspawner
python310Packages.dockerspawner.dist
python310Packages.jupyterhub
python310Packages.jupyterhub-ldapauthenticator
python310Packages.jupyterhub-ldapauthenticator.dist
python310Packages.jupyterhub-systemdspawner
python310Packages.jupyterhub-systemdspawner.dist
python310Packages.jupyterhub-tmpauthenticator
python310Packages.jupyterhub-tmpauthenticator.dist
python310Packages.jupyterhub.dist
python310Packages.oauthenticator
python310Packages.oauthenticator.dist
python311Packages.batchspawner
python311Packages.batchspawner.dist
python311Packages.dockerspawner
python311Packages.dockerspawner.dist
python311Packages.jupyterhub
python311Packages.jupyterhub-ldapauthenticator
python311Packages.jupyterhub-ldapauthenticator.dist
python311Packages.jupyterhub-systemdspawner
python311Packages.jupyterhub-systemdspawner.dist
python311Packages.jupyterhub-tmpauthenticator
python311Packages.jupyterhub-tmpauthenticator.dist
python311Packages.jupyterhub.dist
python311Packages.oauthenticator
python311Packages.oauthenticator.dist

47 packages built:

balanceofsatoshis
bitwarden-cli
castnow
commitlint
concurrently
create-cycle-app
emacsPackages.lsp-bridge
emanote
emanote.data
fast-cli
flexoptix-app
gtop
joplin
lighthouse
lv_img_conv
morgen
openmoji-black
openmoji-color
pm2
postcss-cli
pscid
pulsar
pyright
redoc-cli
slack
teams
theLoungePlugins.plugins.closepms
theLoungePlugins.plugins.giphy
theLoungePlugins.themes.abyss
theLoungePlugins.themes.flat-blue
theLoungePlugins.themes.flat-dark
uppy-companion
vimPlugins.coc-metals
vimPlugins.coc-pyright
vimPlugins.coc-stylelint
vimPlugins.markdown-preview-nvim
vscode
vscode-extensions.ms-python.vscode-pylance
vscode-extensions.rust-lang.rust-analyzer
vscode-fhs
vscode-with-extensions
vscodium
vscodium-fhs
wasm-text-gen
wrangler
yaml-language-server
zx

@ixxie @cstrahan I'm going to merge for now, but the failures appear to be only due to the jupyterhub failure. It looks like a sqlalchemy failrure in a test, but I didn't investigate.
Feel free to ping me if you have any PRs for a fix.


The last message on chat window is hidden if I click on message field to show keyboard

The last message on chat window is hidden if I click on message field to show keyboard

thanks for posting the issue, try out the new APK

Fixed, thanks.

A new problem was introduced. Now on a chat with for example only two messages, when clicking on message field, the two messages disappear.

Reopen as the problem is back on the new version.