[HOLD App # 28618] Request & send money - User is redirected to Amount page from Amount page from deep link

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: 1.3.87-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
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/29655
Action Performed:

Go to staging.new.expensify.com
Paste Request money link (https://staging.new.expensify.com/request/new
) to any chat,
3, Click on the link above.
Enter amount and click Next.
Repeat Step 2-4 with Send money link (https://staging.new.expensify.com/send/new
).

Expected Result:
User will be redirected to the next step of the Request money/Send money process
Actual Result:
The process is looped. Instead of proceeding to the next step, user lands on the enter amount page again
Workaround:
Unknown
Platforms:

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

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

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/78819774/39517ebe-aec8-4659-b056-7511003924ce

MacOS: Desktop

View all open jobs on GitHub

Proposal
Please re-state the problem that we are trying to solve in this issue.
User redirected from amount page to amount page (instead of participants page) when using deep link
What is the root cause of that problem?
The problem occurs when there is a mismatch between iouType (which is found from route params) and iou.id which is found from the IOU value saved in ONYX. So if the value of the iou was 'request' and we are creating 'send' iou or vice versa navigateToNextPage resets the iou value. Because of this line
https://github.com/Expensify/App/blob/eb5fec2c258e74a69bbed9d93100db4b30b265ec/src/libs/actions/IOU.js#L2863-L2871
But the resetMoneyRequestInfo function resets all the iou properties including iou.amount (to 0). So in the MoneyRequestParticipantsPage this lines of code will navigate it back because iou.amount is 0.
https://github.com/Expensify/App/blob/eb5fec2c258e74a69bbed9d93100db4b30b265ec/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsPage.js#L97-L99
What changes do you think we should make in order to solve the problem?

We need to update resetMoneyRequestInfo to have the option not to reset the amount if needed. Like this,
function resetMoneyRequestInfo(id = '', donResetAmount = false) {     const created = currentDate || format(new Date(), CONST.DATE.FNS_FORMAT_STRING);     Onyx.merge(ONYXKEYS.IOU, {         id,         ...(!donResetAmount && {amount: 0}),         currency: lodashGet(currentUserPersonalDetails, 'localCurrencyCode', CONST.CURRENCY.USD),         comment: '',         participants: [],         merchant: CONST.TRANSACTION.DEFAULT_MERCHANT,         category: '',         tag: '',         created,         receiptPath: '',         receiptFilename: '',         transactionID: '',         billable: null,     }); }
and  replace
https://github.com/Expensify/App/blob/eb5fec2c258e74a69bbed9d93100db4b30b265ec/src/libs/actions/IOU.js#L2863-L2871
to
function navigateToNextPage(iou, iouType, report, path = '') {     const moneyRequestID =${iouType}${report.reportID || ''}`;
const shouldReset = iou.id !== moneyRequestID;
// If the money request ID in Onyx does not match the ID from params, we want to start a new request
// with the ID from params. We need to clear the participants in case the new request is initiated from FAB.
if (shouldReset) {
    resetMoneyRequestInfo(moneyRequestID, true);
}

`
Result
https://github.com/Expensify/App/assets/38649957/6bfcf33e-35a8-4c27-b10c-c7e1d6de9689
What alternative solutions did you explore? (Optional)

Proposal
from: @cooldev900
Please re-state the problem that we are trying to solve in this issue.
If a user clicks on a link to request money (eg: https://staging.new.expensify.com/request/new), enter an amount, click next and then proceed to click on a link to send money (eg: https://staging.new.expensify.com/send/new), the amount will be pre-populated but after clicking next, it will render the amount screen again.
What is the root cause of that problem?
The problem is that a single IOU object is used for both send and request money screens, and the id of IOU object will become "" after new request is handled because both sendMoney(send) and createTransaction(request) in MoneyRequestConfirmPage calls resetMoneyRequestInfo function without id.
https://github.com/Expensify/App/blob/8dba113c233c0a433e81a637ea6c28ca815b3f02/src/libs/actions/IOU.js#L124-L141
https://github.com/Expensify/App/blob/302cebf14c4e0fcd6570ac66e9d85a1ca0212ae6/src/pages/iou/steps/MoneyRequestConfirmPage.js#L295-L311
https://github.com/Expensify/App/blob/302cebf14c4e0fcd6570ac66e9d85a1ca0212ae6/src/pages/iou/steps/MoneyRequestConfirmPage.js#L295-L311
https://github.com/Expensify/App/blob/8dba113c233c0a433e81a637ea6c28ca815b3f02/src/libs/actions/IOU.js#L1259-L1279
https://github.com/Expensify/App/blob/8dba113c233c0a433e81a637ea6c28ca815b3f02/src/libs/actions/IOU.js#L2513-L2519

After clicking request button in MoneyRequestConfirmPage, the id of IOU object will be empty so shouldReset becomes true due to  "" !== "request" or "send"  and then !isDistanceRequest && ((iou.amount === 0 && !iou.receiptPath) || shouldReset) turns to true so that navigateBack function lets the user to get back to amount page again.
And
if (shouldReset) {
      IOU.resetMoneyRequestInfo(moneyRequestId);
  }

could be another reason in next refresh.
https://github.com/Expensify/App/blob/302cebf14c4e0fcd6570ac66e9d85a1ca0212ae6/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsPage.js#L92-L99
What changes do you think we should make in order to solve the problem?
Calling the resetMoneyRequestInfo in IOU.js let a user get back to report page automatically but when we visit request/new page directly, we need to take an account if the iou.id is set or not to avoid getting back to amount page again.
useEffect(() => {
        if (!iou.id && (lodashGet(route, 'params.iouType', '') === CONST.IOU.TYPE.REQUEST || lodashGet(route, 'params.iouType', '') === CONST.IOU.TYPE.SEND)) {
            IOU.resetMoneyRequestInfo(lodashGet(route, 'params.iouType', ''));
        }
    }, [iou.id, route.params])

What alternative solutions did you explore? (Optional)
N/A

Proposal
Please re-state the problem that we are trying to solve in this issue
If a user clicks on a link to request money (eg: https://staging.new.expensify.com/request/new), enter an amount, click next and then proceed to click on a link to send money (eg: https://staging.new.expensify.com/send/new), the amount will be pre-populated but after clicking next, it will render the amount screen again.
What is the root cause of that problem?
The issue here is that the same IOU object
{
amount:0
category:""
comment:""
created:"2023-10-19"
currency:"INR"
id:"request"
merchant:"Request"
participants:[]
receiptFilename:""
receiptPath:""
tag:""
transactionID:"8311076577222983710"
}

is used for both sending and requesting money but with opposite id's i.e, When you send money, it's labeled with the "receive" ID, and when you request money, it's labeled "send".
Which results : iou.id = 'send' and iouType = 'request'.
This is handled in navigateToNextPage function
https://github.com/Expensify/App/blob/18acd82f40153fc1e5091aea3217c532142e500e/src/libs/actions/IOU.js#L2863-L2871
which creates the new request
What changes do you think we should make in order to solve the problem?
We need to reset the IOU if id is not matched through resetMoneyRequestInfo(moneyRequestID)  in else case here
https://github.com/Expensify/App/blob/18acd82f40153fc1e5091aea3217c532142e500e/src/pages/iou/steps/NewRequestAmountPage.js#L96-L121
like
else{
            const moneyRequestID = `${iouType}${reportID}`;
            const shouldReset = iou.id !== moneyRequestID;
            if (shouldReset) {
                IOU.resetMoneyRequestInfo(moneyRequestID);
            }

What alternative solutions did you explore? (Optional)
NA
POC
https://github.com/Expensify/App/assets/47495619/15c3c12c-1c9e-4624-8f1c-e85fb26938af

Def seems like a bug. @Ollyws thoughts on the above proposals?

Great, ty!

@Ollyws Got it. That PR does look pretty similar to what I tried locally, so yeah, let's avoid that. What about my alternative solution? The idea is to simply reset the IOU every time the screen is first loaded. It's similar to what startMoneyRequest does, but because the route is being loaded from a link, we don't have a chance to reset it before it loads. So instead we reset it on the component level, when the screen loads using, for example:
    useEffect(() => {
        resetMoneyRequestInfo();
    }, []);

Also, we would do it on MoneyRequestSelectorPage.js instead of NewRequestAmountPage.js as NewRequestAmountPage, NewDistanceRequestPage and ReceiptSelector all depend on IOU and not reseting them when on any of the other screens could have unexpected site effects just like this one we're dealing with.

@Ollyws  No I am not modifying code inside isEditing block , Its in else condition.

@Ollyws - do you think the bug report here is derivative/has the same root cause as this issue?

Ongoing discussion about solutions

@Ollyws curious if you think we're close to being able to select any of these proposals?

Still pending more discussion on proposals

@Ollyws what if we reset on mount, but only if url type parameter does not match the current IOU type in Onyx? Downside is clicking on a link from chat would not reset unless type changes but at least it will behave better (this is current behavior anyways, so still a net positive).
Unless there’s a way to intercept the link click, determine that it’s opening either a send or request screen and only then reset (I’ll try to look into this option)

Proposal
Updated

Pending more discussion on proposals

@Ollyws are we close to selecting a proposal here?

@Ollyws thanks for reviewing my proposal. Looks like Upwork job failed to post. I'll get a PR ready for review once the job is posted.

@barros001 Hi! As a heads up, your proposal has not been officially selected until you've been assigned to the issue. Right now, we're waiting for @luacmartins to do a final review here. Once you're assigned, you'll be invited to the Upwork job.
LMK if you have any questions. Thanks!

Agree that @barros001 proposal looks good. Assigning @barros001 to the issue.

I found the Upwork job by searching Upwork (it was created but never linked here). Upwork decided that it needs to verify my account before I can apply for the job (it's my understanding the first time I have to apply, then after that I'd be invited). I started the process but might take a day or two.

All good, and sounds good!

Well, it was a lot faster than I thought it would be, my account was verified already and I applied for the job via Upwork.

@barros001 offer sent for $500! Please let us know once the PR is ready for review.

PR is ready for review. Just pending attaching video for Android native, will do as soon as I can get it to run on my dev machine.

I'll put this issue on hold for https://github.com/Expensify/App/pull/28618, since that refactor should fix this.

Yep, I agree! We'll wait and see if that PR fixes this issue. If it does, we'll still issue payment and close this out. If not, we'll proceed with the PR.

Held

Other PR was deployed to staging today. Going to retest there.

Restested, and now when I go to https://staging.new.expensify.com/request/new I am redirected to a generic error page.

I think this is because the request refactor changed the format of request URLs. @luacmartins thoughts on fixing this?
Perhaps that could be a good pivot for this issue. And instead of going to the above page (where there is no option to leave), we could go to https://staging.new.expensify.com/not-found, which let you go back to the home page.

Problem here is the following:
https://github.com/Expensify/App/blob/2d8523ae3fd8a5b692700a91efb90adac7f1175f/src/ROUTES.ts#L247-L298
https://github.com/Expensify/App/blob/2d8523ae3fd8a5b692700a91efb90adac7f1175f/src/libs/Navigation/linkingConfig.ts#L393-L410
https://github.com/Expensify/App/blob/2d8523ae3fd8a5b692700a91efb90adac7f1175f/src/pages/iou/MoneyRequestSelectorPage.js#L123-L139
The /request/new route has been replaced but it's still there because money request routes will catch ANYTHING/new and try to render MoneyRequestSelectorPage. If iouType is invalid, it will render a not-found screen, but request IS valid. The app will continue rendering the old request money screen and it will fail because CONST.TAB.DISTANCE, CONST.TAB.MANUAL, and CONST.TAB.SCAN no longer exist. The same will happen to split (not sure if split have been migrated or not).
To me looks like we're in this transition phase where this route/screen has to exist because send still uses it. Do we plan to transition send as well and eventually get rid of the old screens? If that's the case I suggest we do the following:
Update the should show check to this:
shouldShow={!IOUUtils.isValidMoneyRequestType(iouType) || !isAllowedToCreateRequest || [CONST.IOU.TYPE.REQUEST, CONST.IOU.TYPE.SPLIT].includes(iouType)}

And get rid of this if block:
https://github.com/Expensify/App/blob/2d8523ae3fd8a5b692700a91efb90adac7f1175f/src/pages/iou/MoneyRequestSelectorPage.js#L111-L141
This will make it so request/new behaves the same way as invalidioutype/new until everything is migrated away and this routes/screens are completely removed.

Ah, actually I think we just fixed that here.

Chatted with @luacmartins and there's nothing else we need to fix here. I just need to pay $500 to each of @barros001 and @Ollyws and then close this out. Will take care of that tomorrow!

@barros001 $500 sent and contract ended!

Upwork job auto closed, so opened a new one to pay @Ollyws

@Ollyws offer sent for $500!

Paid! Closing as this is all set.


LeaderBoard sources with tests

Hi Emily,
LeaderBoard with tests in C# written based on java version.
Bruno

Thankyou!

All pleasure is for me, Emily :-)


Async/Multithreading

SInce multiple hoards can be processed at once and each one may have multiple files, it may make sense to have multiple operations perform at once.
Not sure if this is best done with an async runtime like Tokio or making some background worker threads myself. A worker queue of some sort makes sense. I'll have to look into what is simplest to implement.

You could look into smol. But know that File I/O is blocking anyway, so introducing async thread pools is not going to make File I/O any faster. You may be better off just having a background thread for sending all I/O tasks to. Doesn't necessarily have to be async, but you could leverage smol's primitives if you want to ensure files in the background thread are successfully writing before proceeding to the next CPU task.

After thinking on this further, I agree that multiple threads for just file I/O doesn't really make sense. What may make sense -- and I will benchmark it when the time comes -- is using multiple threads to work with encrypted files, e.g. threads each for reading, en/decrypting, and writing. Again, I'll need to benchmark that to see if it is even worth the extra complexity.

Update on this: I created the fs-optimization branch to explore this.

Processing time drops from 10 minutes to ~1 when using multi-threaded tokio over single-threaded std
[ ] Some existing code needs to be refactored to avoid async recursions, as it seems to be causing stack overflows on Windows.
[ ] The (admittedly fragile) tests for hoard edit stall on Linux, but seem to be fine on Windows. Behavior is manually tested to work correctly on Linux, so it's a problem with the test itself.

The test is the most complex of all of them, and I'm not sure the complexity and fragility is worth the slight increase in test coverage numbers. Probably better to just make sure things work manually and let that be good enough -- the logic shouldn't change much anyways.


Add arch unit test to check if all injected services are marked with @ServiceScope

Results of the pairing session with @alllex.
The PR introduces a new ArchTest for verifying all injected classes if they have the @ServiceScope annotation.

@wolfs implemented sorting, PTAL!

I wonder how that overlaps with the work the Configuration team has been doing on adding validation to ServiceRegistry itself?
See #26786 and Validate that every service has been annotated in our tech debt catalogue.

I wonder how that overlaps with the work the Configuration team has been doing on adding validation to ServiceRegistry itself?
See #26786 and Validate that every service has been annotated in our tech debt catalogue.

Looking at the mentioned PR, it seems to handle runtime verification of specific injection cases for every Gradle user.
This PR is a sanity check to ensure that inside the codebase, we annotate every injected service with a @ServiceScope.
I could imagine doing this verification run-time later on, but it definitely helps to freeze and enumerate all the violations
@alllex feel free to chime in.

@bot-gradle merge

WARN: This is a feature pull request but no changes to release note found.

The merge queue build has started. Click here to see all failures if any.


Add thin ES clients

What changed?

Adding v6 and v7 ES clients compatible with new interface
Bulk processor moved to a separate package

Why?
Bulk processor was moved to avoid cyclic dependency between elasticsearch package and ES clients
New ES clients need to wired in a separate PR

How did you test it?

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 0186ee62-85ec-41cf-9e74-8b7d06228aa4

23 of 49 (46.94%)  changed or added relevant lines in 4 files are covered.
29 unchanged lines in 7 files lost coverage.
Overall coverage increased (+0.005%) to 57.118%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

service/worker/indexer/indexer.go
2
4
50.0%

common/elasticsearch/client_v6_bulk.go
14
19
73.68%

common/elasticsearch/client_v7_bulk.go
0
19
0.0%

Files with Coverage Reduction
New Missed Lines
%

common/task/weightedRoundRobinTaskScheduler.go
2
89.64%

common/util.go
2
52.31%

service/history/execution/mutable_state_util.go
2
36.04%

service/history/task/transfer_active_task_executor.go
2
72.15%

service/matching/matcher.go
2
91.46%

common/task/fifoTaskScheduler.go
4
82.47%

service/history/execution/mutable_state_task_refresher.go
15
66.77%

Totals

Change from base Build 0186ed8c-939f-4cc5-9459-fac2c80653f9:
0.005%

Covered Lines:
85275

Relevant Lines:
149297

💛  - Coveralls

Since there seems to be a substantial amount of new code in here:
what's the goal / purpose?  and/or where are these new requirements coming from, since no libraries have been upgraded?
(part of this is that I'm simply unfamiliar with this code, it might be obvious)

Since there seems to be a substantial amount of new code in here: what's the goal / purpose? and/or where are these new requirements coming from, since no libraries have been upgraded?
(part of this is that I'm simply unfamiliar with this code, it might be obvious)

As this and https://github.com/uber/cadence/pull/5168 are related, let me add some more context here:

olivere v6/v7 libraries now are deprecated and author recommends to use "official" Elasticsearch clients.
There will be no olivere v8
I'm adding support for Opensearch client

To reuse business logic while using different versions of Elasticsearch/OpenSearch, we have to keep "versioned" clients small and only doing client/server communication.
https://github.com/uber/cadence/pull/5168 adds a possibility to build queries in identical way but without depending on external packages/structs.
The code in this PR is not used right now, but needs to be wired in the next PR: common/elasticsearch/client_{v6|v7}.go will be replaced with a single client.go and will use code provided in this PR.


Chore: Code authoring updates 📝

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


LaMDA : Language Models for Dialog Applications

집현전 최신반 스터디

2022년 5월 22일 일요일 10시
류영표님 김대규님 금지헌님
논문 링크: https://arxiv.org/abs/2201.08239

Abstract
We present LaMDA: Language Models for Dialog Applications. LaMDA is a family of Transformer-based neural language models specialized for dialog, which have up to 137B parameters and are pre-trained on 1.56T words of public dialog data and web text. While model scaling alone can improve quality, it shows less improvements on safety and factual grounding. We demonstrate that fine-tuning with annotated data and enabling the model to consult external knowledge sources can lead to significant improvements towards the two key challenges of safety and factual grounding. The first challenge, safety, involves ensuring that the model's responses are consistent with a set of human values, such as preventing harmful suggestions and unfair bias. We quantify safety using a metric based on an illustrative set of human values, and we find that filtering candidate responses using a LaMDA classifier fine-tuned with a small amount of crowdworker-annotated data offers a promising approach to improving model safety. The second challenge, factual grounding, involves enabling the model to consult external knowledge sources, such as an information retrieval system, a language translator, and a calculator. We quantify factuality using a groundedness metric, and we find that our approach enables the model to generate responses grounded in known sources, rather than responses that merely sound plausible. Finally, we explore the use of LaMDA in the domains of education and content recommendations, and analyze their helpfulness and role consistency.

최신반 2조 발표자료입니다.
https://drive.google.com/file/d/1S8AFlg04b1kHYSpzgpN3uyAtBxvAB2Em/view?usp=sharing

발표 링크: https://www.youtube.com/watch?v=kaEB-mp4jL8&list=PL2tRglRS_GqivYoDuzLNo_HezOvh4Z1XN&index=8


Adds completion callback to removeAllObjects

We use AwesomeCache in our project, and we want to reliably test removal of objects from our cache. To do this, we have to wait for the files to be removed from disk. There was no way to do this without having a callback in the removeAllObjects method, so we added one.

Thanks a lot. :sparkles:


Cargo package existence and package version existence logic update.

The check for if a package exists, or if a package version exists, and the list of package versions that do exist for a package is a bit broken for cargo, it appears to be constantly getting 403s as we get throttled.
This PR updates it to use their registry mirror on github as per the recommendations on https://crates.io/data-access to use https://github.com/rust-lang/crates.io-index

@scovetta looks like the libraries.io unit test is failing on the pipeline? I got it to work locally after pasting in my API Key, is it not set up correctly for the pipeline?

I don't think they expire, might be getting throttled. I'll take a look.


Add original description on cascade MR

In our workflow, we always create an MR to solve a GitLab issue. Thus we're excepting that when MR is resolve that issue is automatically close if using GitLab issue closing pattern
The problem is that GitLab, only closing issue on default branch and GitLab could have only 1 default branch per repo.
In our case default branch is always latest version, here for example 3.0.0 (in following example, 3.0.0 is using meta/trunk branch main unlike 2.3.1 which is linked to main/2.3.1) . But if we've to fix on 2.3.1 we'll create a merge request on main/2.3.1 with for example description containing
fixes #XXX

and ucascade will correctly create a merge request automatically but original description with fixes #XXX will not part of description of this newly created MR.
I've already forked for our need but I'd like to know if is something that you're interested and thus I could propose a PR (it could be configurable and disabled by default).
In our fork version MR will looks like (I've also done some style update, like adding icon and emphasis)

by default original description is using built-in <summary> tag to be fold, but if you can unfold you could see (here our description is complete, is just short description :) because in our workflow most of information already part of issue. Thus there is no filtering on original description).
And if you've multiple level of cascade, it will always take the original (starting point) description not n-1!

And so at then end, on the issue link will be conserved/cascaded and as soon that ucascade MR will reach our default branch the issue will be automatically close (in case there is an issue closing pattern)

Thank you very much for this detailed issue.
We are not using GitLab issues yet, but this sounds a very useful addition to ucascade.
I don't think we need to make this configurable, since I can't imagine a case where the fixes #XXX mention should not be transferred to the next merge requests (the config flag could be added later if needed).
Also I think your styling of the MR description looks nicer and can be integrated.
So feel free to open a PR so that we can integrate your change in the main branch.

I don't think we need to make this configurable, since I can't imagine a case where the fixes #XXX mention should not be transferred to the next merge requests (the config flag could be added later if needed).

Is more my conservative spirit 😆 and to do not break existing usage.
I always think configuration, even if we choose, in this case, to put it to true by default unlike I just proposed is always better than hardcoded because each people have always different needs or workflows
I'll cleanup a bit my fork and push PR

Yes sorry. Few off days on France ☺
I'll push PR tomorrow. Code is clean enough is more commit log to cleanup


How make stored procedure in prisma?

I have not found documentation on this please someone knows how to implement store procedure in prism

@CarlFMateus
Prisma currently doesn't support procedures or views so we can treat this issue as a feature request.


Adapter Tests

Right now only the ember-changeset adapter is tested. We will want to add tests for ember-data adapter prior to releasing this addon.

Updated in fbf0ad993b681aae920ef68bc16d1a6a1254404b, but still missing form adapter tests for ember-data validation adapters


MVP-3445: Fix Solana 'use hardwallet' not showing when destination is not required

In the react-card, when “Require Destinations” is turned off the signup page does not render the input fields including the “use hardware wallet” toggle for Solana with the hw wallet package. However the user needs to sign a message to login so will end up in a locked state where they cannot register at all. This will prevent any Solana users using a hw wallet from signing up to any dapp notifications. We should render the “use hardware wallet” toggle even if require destination is turned off.

merging to cut a new release


this guy(or girl) copied my bookmarklets

why man(or woman), whyyyyy
i didn't say u couldn't use them but atleast credit me for some of my work
this is not a bug this is just a public report
also you readme file is grammatically incorrect (it is here not hear(hear means listen or something))

Sorry!!! i will give you credit!!

BTW, i think this is Fair Use.  You never mentioned anything about giving you credit.  i have included all comments giving credit to the person.

but it's obvi right man or woman(or both, I do not want to sound rude)

also if you want you can include tis bookmarklet:-
javascript:location.replace('https://www.'+prompt('website url?'));

@Nakul-Ardeshana, do you want to be a contributor?  All i need is to keep finding bookmarklets.

yea you still have many grammatical mistakes you can check them on Grammarly


[audio] Music looping based on FPS issue

[x] I tested it on latest raylib version from master branch
[x] I checked there is no similar issue already reported
[x] My code has no errors or misuse of raylib

Issue description
Music looping is based on FPS, which is odd in 99% of time.
With this approach, if the music reach the end of its own length, you have to wait the next frame to restart looping.
It was tried of course using WAV pcm file with basic code:
Environment
Windows 10, mingw_w64, GTX1050 3gB
Provide your Platform, Operating System, OpenGL version, GPU details where you experienced the issue.
Issue Screenshot

Code Example
(sfx.wav is downloadable here: http://kabcorp.fr/sendfiles/ray/sfx.wav)
sfx.wav is a pure sine wave with correct repeat sample.
#include <raylib.h>

int main(void)
{
    int Fps=30;
    InitWindow(700, 200, "Music Loop Issue");
    SetTargetFPS(Fps);

    InitAudioDevice();

    Music Sfx=LoadMusicStream("sfx.wav");
    PlayMusicStream(Sfx);

    while (!WindowShouldClose())
    {
            UpdateMusicStream(Sfx);

            Fps+=(IsKeyPressed(KEY_RIGHT)-IsKeyPressed(KEY_LEFT))*10;
            Fps=Fps < 10 ? 10 : Fps;
            SetTargetFPS(Fps);

            BeginDrawing();
            ClearBackground(GRAY);

            DrawText(TextFormat("(Press L/R to change FPS)\n%i/%i fps", GetFPS(), Fps), 8, 8, 20, LIGHTGRAY);

            EndDrawing();
    }

    CloseWindow();
    UnloadMusicStream(Sfx);
    return 0;
}

@Kabcorp Yes, I'm aware of this issue, raudio module needs some improvements on that regards. There are some open PRs on that line but not completely reviewed yet.

This may be a related issue, but if I play a short music clip without looping, the music stops prematurely. The next time I say to play the sample clip it will pick up where it left off and then loop from the beginning again. Not sure if you'd like this as a separate issue or not?

Could you tell me if this issue is still being worked on?

@jdeokkim this issue is open but I'm not working on it right now. Feel free to work on it and send a PR if you wish.

@raysan5 Oh, I see. Thank you!

I've had a look at this and I'm not actually sure what's going on. When I tried it, I also had another glitch with wav files which I'm not sure is related.
I'm strongly of the opinion that the audio system needs a complete overhaul. And by that I mean both the implementation and the public API. Generally, these are the high level things I think you need to change.

You have a bunch of separate code paths for loading different file formats. Just use ma_decoder from miniaudio. For formats that are not supported natively by miniaudio, plug in a custom decoder. That way all loading is done in a unified manner via ma_decoder_*(). This would certainly simplify loading code and make it easier to debug.
There are separate objects for "AudioStream" and "Music" and "Sound". When you break them down they're all the same thing - they're just sounds. The only difference is how data is delivered. Just have a unified "Sound" API and get rid of the other two. You can still have functions for initializing the "Sound" object as a stream (maybe LoadSoundStream() or something) which will enable a function like UpdateAudioStream().
You're still using the low-level API and doing mixing yourself. You could simplify the code significantly by just using ma_engine and let miniaudio do the mixing for you. I think it's just this way because you started using miniaudio way before the high level stuff came out.

If you're willing to do a complete rewrite of the audio system (which I think you should seriously consider), I'd be happy to do a fresh implementation with you. My preference would be to do a complete redesign of the audio API though which would obviously break compatibility, but I have ideas that I think could make the audio system even simpler for the user and at the same time make it more powerful. Happy to talk further about that if you're interested.

Hi David! Thank you very much for taking a look to this issue! I agree that the audio system needs a review, I know miniaudio has grown a lot in the last years and provides lots of high-level features but redesigning the public API will be a breaking change I prefer to avoid at this moment; at least not intended for the upcoming raylib 4.2 release.

You have a bunch of separate code paths for loading different file formats. Just use ma_decoder from miniaudio. For formats that are not supported natively by miniaudio, plug in a custom decoder. That way all loading is done in a unified manner via ma_decoder_*(). This would certainly simplify loading code and make it easier to debug.

Current implementation discretizes the different file formats loading using SUPPORT_FILEFORMAT_* and it keeps the data and/or the context stored in the structure, it would be great to remove that context, at least from user exposure, how would it be using ma_decoder approach? I like from current implementation the transparency of every file format, seeing the libraries used for every format.

There are separate objects for "AudioStream" and "Music" and "Sound". When you break them down they're all the same thing - they're just sounds. The only difference is how data is delivered. Just have a unified "Sound" API and get rid of the other two. You can still have functions for initializing the "Sound" object as a stream (maybe LoadSoundStream() or something) which will enable a function like UpdateAudioStream().

Current approach uses Sound and Music data types, both include a AudioStream type that implements the AudioBuffer. The structs are simple and just expose the basic elements to the user, also considering they are mostly passed by value, that's a common approach in all raylib functions. I would like to maintain the current API (or most of it) but maybe it will be possible to jsut have AudioStream and make the Sound and Music types an alias of it, what do you think?

You're still using the low-level API and doing mixing yourself. You could simplify the code significantly by just using ma_engine and let miniaudio do the mixing for you. I think it's just this way because you started using miniaudio way before the high level stuff came out.

Agree. That would be a nice improvement. As per my understanding this is mostly an internal change, right?

My preference would be to do a complete redesign of the audio API though which would obviously break compatibility, but I have ideas that I think could make the audio system even simpler for the user and at the same time make it more powerful. Happy to talk further about that if you're interested.

Sure! At this moment I'm targeting raylib 4.2 release and I'm a bit reticent of API breaking changes but I want to hear your ideas and we can see how we can redesign the API for a future version.

Current implementation discretizes the different file formats loading using SUPPORT_FILEFORMAT_* and it keeps the data and/or the context stored in the structure, it would be great to remove that context, at least from user exposure, how would it be using ma_decoder approach? I like from current implementation the transparency of every file format, seeing the libraries used for every format.

The way it would work is the context would be a ma_decoder instead of drwav, drmp3, etc. The MusicContextType enum would no longer be necessary for discriminating against the different types. For formats that are not supported internally by miniaudio, such as XM and MOD, a custom decoder can be implemented and plugged into miniaudio. This is a much cleaner separation of interests and will keep the code much easier to maintain.
For example, in UpdateMusicStream(), you have code that looks like this:
switch (music.ctxType)
{
#if defined(SUPPORT_FILEFORMAT_WAV)
    case MUSIC_AUDIO_WAV:
    {
    } break;
#endif
#if defined(SUPPORT_FILEFORMAT_OGG)
    case MUSIC_AUDIO_OGG:
    {
    } break;
#endif
#if defined(SUPPORT_FILEFORMAT_FLAC)
    case MUSIC_AUDIO_FLAC:
    {
    } break;
#endif
#if defined(SUPPORT_FILEFORMAT_MP3)
    case MUSIC_AUDIO_MP3:
    {
    } break;
#endif
#if defined(SUPPORT_FILEFORMAT_XM)
    case MUSIC_MODULE_XM:
    {
    } break;
#endif
#if defined(SUPPORT_FILEFORMAT_MOD)
    case MUSIC_MODULE_MOD:
    {
    } break;
#endif
    default: break;
}

That entire section would be replaced with a call to ma_decoder_read_pcm_frames():
ma_decoder_read_pcm_frames((ma_decoder*)music.ctxData, frameCountToStream, (float*)AUDIO.System.pcm);

It's just so much cleaner. No #if blocks and no need for discriminating against the file type and then having separate branching logic everywhere. It'll also just make it so much easier to reason with when debugging.

Current approach uses Sound and Music data types, both include a AudioStream type that implements the AudioBuffer. The structs are simple and just expose the basic elements to the user, also considering they are mostly passed by value, that's a common approach in all raylib functions. I would like to maintain the current API (or most of it) but maybe it will be possible to jsut have AudioStream and make the Sound and Music types an alias of it, what do you think?

Could be possible, but I haven't really looked at the code in enough detail. Certainly if you couldn't make it an alias, you could simplify them a bit. There's something that feels wrong about the double buffering system that's currently being used - I think that needs to be re-written and simplified, and I have an idea for that. I'm suspecting that has something to do with the error in this bug report.
But yes, there's still a bunch we could do to improve the code while keeping the same API. They way I would approach it is to first do that unified decoding thing. After that I would transition away from the low-level API and start using the high level API so you can avoid having to do the mixing yourself.

The way it would work is the context would be a ma_decoder instead of drwav, drmp3, etc. The MusicContextType enum would no longer be necessary for discriminating against the different types. For formats that are not supported internally by miniaudio, such as XM and MOD, a custom decoder can be implemented and plugged into miniaudio. This is a much cleaner separation of interests and will keep the code much easier to maintain.

Agree. This approximation is more cleaner.

Could be possible, but I haven't really looked at the code in enough detail. Certainly if you couldn't make it an alias, you could simplify them a bit. There's something that feels wrong about the double buffering system that's currently being used - I think that needs to be re-written and simplified, and I have an idea for that. I'm suspecting that has something to do with the error in this bug report.

That's nice. I personally never liked the double-buffer approach.

They way I would approach it is to first do that unified decoding thing. After then once that's done I would transition away from the low-level API and start using the high level API so you can avoid having to do the mixing yourself.

That's sounds good for me. @mackron we can start working on it on the raudio repo if you want and once we have something good enough I will move it into raylib. Currently raudio.c is the same as raylib module and raudio.h implements the API exposed by raylib.h.

This issue has been fixed but the raudio module needs a good redesign, as commented above.


Remove 160 2018-09-06 terms that are unchanged from 2017-10-06

See #262: 160 terms with version 2018-09-06 are unchanged duplicates of the 2017-10-06 version. They are the result of a catch all change of all terms in this commit. This PR reverts this by removing the 2018-09-06 versions and reinstating the 2017-10-06 terms as recommended.
31 terms in the 2018-09-06 are actual changes: those are kept.

I ran the build script and this PR does not affect the quick ref guide.


Remove the DEVELOP_IN_ECLIPSE support

The support to develop in eclipse is no longer supported
and removed.
Resolves #383

@lukehinds Do we still use STUB_TPM and TPM_CANNED_VALUES in the CI?


Fix hooks 'useAuthheader' and 'useAuthUser'

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] I have read the CONTRIBUTING document.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

ISSUES CLOSED: #63

@v1b3m Thanks a lot. 🎉🎊 You did a great job. Don't forget to Star ✨ the Repo. Thanks again

@v1b3m Thanks a lot. tadaconfetti_ball You did a great job. Don't forget to Star sparkles the Repo. Thanks again

Thank you @darkmatter18 for this great work.


Bug In Mobile View : Closes #1134--> Toggle Mode Not Working In Mobile View

Fix #1134
Bug
Image 1

Image 2

After Fix
Image 1

Image 2

@sanjay-kv Please Check the above pull request


pytest: fix comparing asserts

The plugin adapts pytest's output of (in)equality assertions to the format expected by PyCharm's comparison tool. However it gets truncated values from pytest which makes the comparison mostly useless. This fix overrides the truncation(s), and further improves the comparison by making it multiline (for comparing complex structures).

override pytest_assertrepr_compare to work around pytest's SafeRepr truncation
enable verbose mode to disable pytest's truncation of lines
reverse pytest's escaping of newlines (to enable multiline comparison in PyCharm)

(yay, didn't realize there's tests — will review the failures and fix)

ping @shalupov

service messages are limited in length. I'll ask TeamCity whats the current limitation.

Alright. I was relying on this for local pytest invocations in PyCharm. If TeamCity imposes stricter limitations than local invocations, can they be told apart?

I've checked, currently there are no known limits. Thanks for the PR


Add examples folder to demonstrate full Veracruz use cases

Create an examples folder where each example shows how to put all components together (program owner, data owner, policy, wasm binary ..), maybe examples can be driving by different Veracruz use cases.

I think this is a good idea.  At the moment we have:

examples of how you write a program for Veracruz under sdk/examples,
full-system integration tests under sinaloa-test and veracruz-test which are not written in an especially-clear way (see also #3, which I think is closely related to this) and fetch their required bits-and-pieces from all over the place in the repository (e.g. the policies, WASM binary, etc.)

...but no directory that collects a few simple examples together, with WASM program, policy, client code, scripts for deploying a Veracruz isolate, etc. all in one place to get newcomers going with the project.  Moreover, some of these examples could be tied to some of the use-cases that we discuss in the README file, which would be a nice tie-in.

This might be a duplicate of #3

I wasn't sure at first whether this was an exact duplicate of #3, but I think you are right.  I'll mark this as a duplicate and close.


OpenTF support

https://opentf.org/announcement
We want to understand how this provider is affected by the OpenTF announcement, and what the plans for support are moving forward.

@skyzyx We don't have any plan to change currently. Since OpenTF is compatible with current and future Terraform releases, all providers should work with OpenTF without any modification.
If and when there are features forking, we will determine our support roadmap then.
In case HashiCorp's BSL announcement and FAQ are not clear, all SDK and plugins remains under Mozilla license so there's no effect to any 3rd party providers.

Thank you for your answer.
From a technical perspective, I expect that it will be a no-op for the time being as OpenTF anticipates maintaining compat/interop for the foreseeable future. (However, OpenTF has stated that some functionality may be added to OpenTF that is a superset of what's in base Terraform. [source])
From a process perspective:

If there is a bug in OpenTF that does not exist in Terraform (or vice-versa), will bug reports (as they pertain to this project) be treated equally on both platforms?

Will testing be performed with code targeting both platforms?

For OpenTF's potential future "superset" functionality, will that be treated as a first-class citizen?

If there is a bug in OpenTF that does not exist in Terraform (or vice-versa), will bug reports (as they pertain to this project) be treated equally on both platforms?

When OpenTF is released and ready to be used/integrated with, then we will need to determine the amount of effort required. Is it literally a 'drop-in' replacement for users and thus nothing required from provider developers? Or some small configuration to toggle between HashiCorp and OpenTF? All of these are unknown at this time, so we can't promise anything either. Of course we hope for the former and even latter and thus we can support both but that's pure hope and speculation at this point.

Will testing be performed with code targeting both platforms?

Hopefully yes, but see answer to #1.

For OpenTF's potential future "superset" functionality, will that be treated as a first-class citizen?

Yes in concept but it really depends on how that is handled by OpenTF at the implementation level.

@skyzyx From my current perspective, this is the current plan:

Given OpenTF promise of backward compatibility, any bug reports will be treated the same. Obviously if we determine the bug is caused upstream in OpenTF (e.g. works in Terraform but not OpenTF), that'll not be fixed by JFrog team.
We will add OpenTF to our CI/CD pipeline so we have confidence that the release is verified for both platforms. The question of if OpenTF will provider their own registry seems to be still opened. So that's TBD for our release process.

This is the information I'm looking for. Thank you.
I certainly don't expect you to resolve upstream bugs, but knowing that OpenTF part of your testing/validation process, and that you would file bug reports upstream when you encounter issues is the level of commitment from JFrog that I'm looking for at the moment. (Also noting any known compat/interop issues in the release notes would be helpful.)
We leverage a lot of tools in the Terraform ecosystem, from open-source tools, to SaaS providers who are firmly in the OpenTF camp due to being "competitive" with HashiCorp. I'm trying to understand not only the position of our internal legal team on the license change, but also the technical impact of OpenTF existing and all of us having to do this dance.
Hoping for the best from all this, but pro-actively planning/communicating for the worst.
Your answers are greatly appreciated. Thank you.


Add possiblity to set account name per job

It would be nice if you could set the account name (parameter -A in PBS) also per job, and not only per job manager

See Pull Request #16


ImportError

How would I solve the ImportError: No module named colorama?

sorry i have not been active i have not even touched my pc but just do "pip install colorama" some of the install commands in the install file might not run for some reason but they should all run if you run "python install.py"


STUN server error handling

What is wrong
Currently when I launch I get this:
STUN claims that public endpoint is: Err("Timeout waiting for STUN server reply")

How can it be fixed
Separate logging message for when we get an error instead of an IP address.

Hah yeah, it was a 5-minute solution that's apparently super unstable. Definitely not a long-term solution, and apparently not really even a medium-term solution.
I just restarted it so it should work for at least a couple more days X)


Update and clean up dependencies

Description
Upgrade the project dependencies to more recent versions, remove unused dependencies, and ensure compatibility with the currently used Solidity version (0.8.19).
Tasks

Review and upgrade all dependencies in package.json that can be updated without breaking changes
Remove unused dependencies from package.json (e.g., solmate)
Upgrade the Bun version used in GitHub Actions
Verify that contracts still build successfully after each update
Read changelogs for each updated dependency and apply any necessary code changes for compatibility

Acceptance Criteria

[ ] All upgradeable dependencies in package.json are updated to their latest stable versions
[ ] Unused dependencies (including solmate) are removed from package.json
[ ] Bun version in GitHub Actions is updated to the latest stable version
[ ] Contracts build successfully with the updated dependencies
[ ] All tests pass with the updated dependencies
[ ] Any necessary code changes for compatibility are implemented and documented

Caveats

Only update to release, battle-tested versions (avoid bleeding edge and beta versions)
Be prepared to revert changes if unexpected issues arise
Determining the latest compatible version for each dependency may take time

Resources

OpenZeppelin Contracts Changelog
Bun releases

@kfastov can I work on this?

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am a Full Stack blockchain Developer with expertise in Next.js, Nest.js, TypeScript, JavaScript, React, Node.js, Three.js, and Solidity. My journey with OnlyDust hackathons began at Edition 1, and I've since made 30 contributions across 9 projects. With my extensive experience on the OnlyDust platform (profile:  https://app.onlydust.com/u/Ugo-X), I've honed my skills in delivering quality solutions under pressure.
I bring a unique blend of technical proficiency and user-focused design to every project, whether it's crafting immersive 3D experiences or developing smart contracts. My track record shows I can adapt quickly and contribute effectively to diverse challenges.
As we surf through Edition 6, I'm excited to leverage my skills and hackathon experience to push the boundaries of blockchain development. I'm confident in my ability to tackle new challenges and drive innovation in this space.
How I plan on tackling this issue
i will be sure to follow the steps mentioned in the description, as the issue is already a very detailed one

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am a web3 developer with 2 years of experience
How I plan on tackling this issue
When i am assigned to this issue i will :

Use only stable, release versions of dependencies.
Be ready to revert changes if issues arise.
Allow time to determine the latest compatible versions.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hi, I am Adrian, I am a passionate developer looking forward to gain some experience in web3 projects. I have some experience using Solidity which might help me with the context of this issue.
How I plan on tackling this issue

Read the code carefully to make sure I know what I am working with
Remove dependencies one by one building the contracts after each deletion to make sure I do not break anything up.
Upgrade the Bun version used in GitHub Actions
Read changelogs for each updated dependency and apply any necessary code changes for compatibility

Hi @kfastov I'd love to contribute to this project. And this looks like a good entry point

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I'm Poulav Bhowmick, with a robust background in TypeScript, fullstack development and blockchain technology. My experience includes building robust applications, optimizing functionalities and blockchain integration. I have actively participated in events and open source contributions, enhancing my capability to tackle real-world tech challenges. My projects can be viewed on my GitHub Profile and OnlyDust Profile. Plus I´m active member of Starknet community🇷. This is my first contribution to Walnut’s Repositories.
How I plan on tackling this issue

Review package.json:

I'll examine each dependency and its current version.
Research the latest stable versions available for each package.
Check compatibility with Solidity 0.8.19 and other project requirements.

Update dependencies:

Upgrade each dependency to the latest compatible version.
Pay special attention to major version changes, reviewing changelogs for breaking changes.
Remove unused dependencies, including solmate.

Update Bun version in GitHub Actions:

Locate the GitHub Actions workflow file.
Update the Bun version to the latest stable release.

Verify builds and tests:

After each significant update, I'll rebuild the contracts to ensure compatibility.
Run the full test suite to catch any potential issues.

Address compatibility issues:

If any problems arise, I'll consult changelogs and documentation.
Make necessary code adjustments to maintain compatibility.
Document any significant changes required.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am Daniel Barrantes, a fullstack software developer passionate about learning new technologies. I have recently entered the world of web3 and I would like to complete my first issue.
How I plan on tackling this issue
-I will read the code carefully to understand the task
-I will update the necessary dependencies and remove the unused ones
-I will verify the correct functioning of the contracts once the changes have been implemented.
-In case of problems, I will work hard to resolve them.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hii,I'm a software developer with over 3 years of experience. I am problem-solving-oriented and i utilize whatever tool oe resource needed to sole any problems i face
How I plan on tackling this issue
I would make good use of the resource as stated in the issue description to effect the updates and also run tests to ensure they work as expected

@Gift-Naomi Hey! I want to remind you that today is the last day to finish the tasks. If there are minor tweaks to your work, they are okay to finish in the following two days 🙂


Question - nameko with alternative Kombu transports (Redis)

Hey guys -- just wondering if you've heard of any nameko use with Kombu transports other than RabbitMQ/AMQP, and specifically Redis.
Presumably(!) leaning on Kombu means things should be transport agnostic, but would be great to hear if anyone has had success in production.

Hey Shaun,
It's very unlikely this would work. We used Kombu because it seemed like the best AMQP library at the time, rather than to be transport agnostic. We rely on certain bits of AMQP and even make use of certain RabbitMQ extensions to the spec.
One of my longstanding desires is actually to remove kombu for one of the newer AMQP libs, so we can support things like publisher heartbeats.

Okay, well that's good to know before I went too far down the rabbit hole (pun intended)

I need to second this...I've found rabbitmq to be very unreliable at scale, especially when paired with modern cluster orchestration (swarm, kubernetes). Would much prefer a redis broker.

Nameko is an extensible framework. There's no reason you couldn't create a set of extensions that implemented Nameko RPC or Events over Redis. The built-in versions are AMQP implementations though, and it would not be worth trying to make them work over a different transport, even with kombu in the middle.

This issue was moved to https://discourse.nameko.io/t/question-nameko-with-alternative-kombu-transports-redis/288


feat(shared-data, app, protocol-designer, api-client): schemaV7 migration

closes RAUT-515 and RAUT-272
Overview
schemaV7 migration!
note: LabwareLocation type excludes labwareId object for now until we know more about the new OnLabwareLocation type Jeremy is making
Test Plan
Smoke test the app, touchscreen, and Protocol-designer to make sure it is all working as expected.
NOTE: uploading a v7 json schema protocol to the app is not yet supported! you'll need to test a python protocol for now.. that work will be done in a follow up ticket https://opentrons.atlassian.net/browse/RSS-282
Changelog

update the types, tests, components to work with schemaV7 types
updated the delay command creator in step-generation to spit out waitForResume or waitForDuration since delay is deprecated

Review requests
see test plan
Risk assessment
touches a lot of code... so medium maybe

@jerader i believe you're already aware (i just remembered/realized), but when importing this PD protocol i made on your branch into the app i get a protocol analysis error:
Error: schema v7 migration test.json could not be read as a JSON protocol.

zipping the file so i can upload it here to github:
schema v7 migration test.json.zip
this makes sense, because the app is using the opentrons analyze cli which doesn't yet know about schema v7. this also means we can't really test these changes at all, and that if we merge this into edge and cut another internal robot stack release, this will probably break LPC and other flows.
sooooo i don't think we can merge this as is. we either need the backend changes, or we only merge PD/step generation changes with a follow up PR coming soon to fix the backend stuff.
when did RSS say that can make the backend changes?

seeing this LPC error on a robot when running a python protocol:

looks like an issue with chain run commands. i think it's this line in app/src/resources/runs/utils.ts
response.data.result.status === 'failed'

looks like an issue with chain run commands. i think it's this line in app/src/resources/runs/utils.ts
response.data.result.status === 'failed'

@shlokamin  Oops ya i see the issue, thank you!


Multiple target languages

Showing users how to translate a website into multiple languages in one go.

Looks good from my side. Only thing left is to squash all the commits into one, and adhere to our conventional commit naming scheme. Probably makes sense to add this to the CHANGELOG.md as well.
Letting Daniel accept here.


Encoding of "null" or scalar in JsonResponse

Hey @weierophinney ,
This is more of an open question than an issue.
In JsonResponse, encoding of "null" is transformed into [].
Encoding of a string like "foo" is transformed into ["foo"].
However, by default,
json_encode(null) === "null";
json_encode("foo") === '"foo"';

I feel that the default behaviour makes more sense, and is less tricky for the user. However, I guess there must be a reason why you wrap scalar types into arrays, and null into an empty array, but I don't understand why.
For information, in other places (Symfony JsonResponse), they seem to transform null into [], but they are not wrapping scalars into arrays. I don't know why either... Any clue why the wrapping?

@moufmouf The transformation of scalars to arrays was originally proposed by @franzliedke.
The rationale is that, while json_encode() and json_decode() can deal with scalar values individually, most JavaScript parsers will not; they expect either an array or object as the root. Thus, the JsonResponse instance wraps all scalars into an array to allow them to remain valid in those contexts.

Indeed.
I didn't even remember that this was done for all scalars, too, but that would make sense, I guess.

@franzliedke It was. :) null becomes an empty object, and then any other scalar is wrapped in an array.
I'm thinking of a small change to the code, however; instead of using ArrayObject to do an empty object, we can more simply do:
if (null === $data) {
    $data = (object) [];
}

and that will be serialized to {}, as it will be a stdClass instance at that point.

But we want [] for NULL, no?

@franzliedke I was just using your code. :) I'm not sure it matters; it's an empty value in either case. If we want [], then it becomes even simpler (we don't need to cast at all). See #64 if you want to comment.

Mmmm... ok, I get the idea.
However, is it still true that most Javascript JSON parser fail to parse null?
Here is a small test:
// In Firefox latest, Chrome latest and IE latest, using the standard JSON object:
JSON.parse("null");
> null
JSON.parse("[]");
> Array [  ]
JSON.parse("{}");
> Object {  }

// In jQuery
jQuery.parseJSON("null");
> null
jQuery.parseJSON("{}");
> Object {  }
jQuery.parseJSON("[]");
> Array [  ]

I could not find a JSON parser in Javascript that is failing to parse "null". Maybe it is a problem from the past and has been wildly fixed? Is this hack still justified today?

APIs are often parsed on servers, too. This wasn't part of an older JSON spec, so I'd argue we should go with that.

More often than not, I expect the JSON returned from an API to be an array or object - something I can iterate or test for properties. As such, a scalar will often result in an error client-side, as the assumptions about what I can do with it fail. So, regardless of whether or not the client can parse it is secondary to whether or not I can do with it what I need to do.

But in JS you also have the problem, that you can't handle arrays and objects equally. I often run into the problem that json_encode transforms an empty assoc into [] instead of {} and then my JS code fails, so I need to cast the empty assoc into ArrayObject or stdClass first on the server. Long story, short. IMO it doesn't make sense to convert scalars into something to help the client, because you cannot be sure what the client expects.

I tend to agree with @codeliner

More often than not, I expect the JSON returned from an API to be an array or object

Completely agree.

As such, a scalar will often result in an error client-side, as the assumptions about what I can do with it fail.

Indeed, but if the server returns "null" or a scalar, and if it is not supposed to, then the server is the source of the error, not on the client. I would actually expect the client to fail fast, because that would help me pinpoint the problem on the server (i.e. fail fast, fail early)

I've updated #64 to implement verbatim serialization (vs. casting).

@weierophinney :+1:

:+1:


docs: [ovh sd] Added missing label for OVH dedicated server in SD

__meta_ovhcloud_dedicated_server_no_intervention label is available for OVH Cloud dedicated server. But it's missing in doc.
See: https://github.com/prometheus/prometheus/blob/da1b7a17b31932e56716c4e3dfc275b66bf3ba8a/discovery/ovhcloud/dedicated_server.go#L149
And previous test case:
https://github.com/prometheus/prometheus/blob/da1b7a17b31932e56716c4e3dfc275b66bf3ba8a/discovery/ovhcloud/dedicated_server_test.go#L65

@machine424 @roidelapluie Hi May I have your review of this PR? Thanks!

For the failing DCO job:
Thanks for your PR. For legal reasons, we require that all commits are signed with a DCO before we can merge them. See this blog post for considerations around this.
This means that the last line of your commit message should read like:
Signed-Off-By: Your Name<EMAIL_ADDRESS>If you are using GitHub through the web interface, it's quickest to close this PR and open a new one with the appropriate line.
If you are using Git on the command line, it is probably quickest to amend and force push. You can do that with
git commit --amend --signoff
git push -f $remote $remote_branch_for_pr

As always, be careful when force-pushing.
Originally posted by @roidelapluie

@machine424 Thanks again. I just fixed it. And sorry for the trouble.

Thanks!


Goal Issue

Goal Issue

[ ] This is main issue creation to understand github

Testing comments

closing comment for this issue


avoid global state in sys and information_schema expressions

can lead to inconsistent results on concurrent queries

changes?

ack


Running webhook in the background

Hi, is there any correct way to run webhook in the background?  i do able to use "nohup" to send the process to backgroung, but this is only works if i execute it directly on terminal. it doesn't work if i put it in cron / other script.
thank you in advance

Lookup a tool called supervisor which will launch a process (webhook) as well as take care of rotating stdout/stderr log files and relaunching process on box reboot ...  http://supervisord.org/
additionally you can in turn wrap supervisor to be a systemd started task
webhook is a daemon so if launched by cron assure you avoid multiple instances of it attempting to run (they will fight over ports) ... if cron launch fails make sure you are sourcing the necessary environment variables neede by your webhook

Hi , thank you for the reply. Yes, i think that's the solution i need for , totally forgot about supervisord because i usually only use that on docker container. Wrapping supervisord in systemd sounds like a good idea, because what i'm trying to do is trying to do with cron earlier is a "at reboot" trigger ensure the webhook still running on server reboot.

From: Scott Stensland<EMAIL_ADDRESS>Sent: Wednesday, October 11, 2017 3:16 AM
To: adnanh/webhook
Cc: FaisalDefry; Author
Subject: Re: [adnanh/webhook] Running webhook in the background (#181)
Lookup a tool called supervisor which will launch a process (webhook) as well as take care of rotating stdout/stderr log files and relaunching process on box reboot ... http://supervisord.org/
additionally you can in turn wrap supervisor to be a systemd started task
webhook is a daemon so if launched by cron assure you avoid multiple instances of it attempting to run (they will fight over ports) ... if cron launch fails make sure you are sourcing the necessary environment variables neede by your webhook
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/adnanh/webhook/issues/181#issuecomment-335670085, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMeBpbN2E0SysLizJQDhqPHbaOA3f9Gaks5srDMTgaJpZM4P0zXj.


Deprecate EVP_MD_CTX_{set_}update_fn()

They are still used internally in legacy code.
Also fixed up some minor things in EVP_DigestInit.pod
Fixes: #14003

Could you please add CHANGES.md entry?

Added CHANGES.md, updated the commit, rebased, pushed.

This pull request is ready to merge

Merged to master. Thank you for your contribution!


Find a new name

As per reddit thread the name is really not good.
@brunoqc do you have any idea for the new name?
I'll settle tomorrow (the sooner the better but I need some time to decide).
Some research on the excel verb:
http://www.merriam-webster.com/thesaurus/excel
Some other candidates

xlrs (eXceLRuSt)
excellent / excel-lent (weird meaning in french as it is not necessarily slow)
exceller (there is a wikipedia page about a "exceller" horse, I like the image https://en.wikipedia.org/wiki/Exceller)
xlsr: variant of 1. but starting with "xls" like excel files
excel-reader

I tend to like 1. the most
Proposed by reddit users:

Excellerator (killercup)

FWIW I came up with excellerator in my head before I finished reading the candidate list.
That or xlrs is 👍 IMO.

Rivets - something use to mount sheet metals together.
Also galvan from galvanized iron

I like rivets!

Prefer excellerator or xlsr. Why not xls?

Thanks for your comment. xls is indeed an option, I'm afraid it is used somewhere (couldn't find any example though)

The only place that matters is https://crates.io/crates/xls

I highly advise against xls with the main argument being that this crated doesn't support the binary xls format.

This is true indeed

Well it does (at least with a high enough biff) the example is just not up to date. There is a running xls test in the tests/tests.rs

Why not just excel_file_reader? It's boringly obvious as to what it does. Remembering puns across languages gets hard...

I think ironically that you remember it less with long names (always mess some part), but this is very personal.
For discoverability I rely on crates.io ...
But I'm very ready to be convinced otherwise

@Havvy Makes a fair point that the name should definitely include excel.
I would definitely search crates.io for excel if I were after a crate like this.

I like Rivets or Sheet Metal

If you go with Rivets make it Rivets-rs as Rivets is an existing js project.

If you still want to keep the project open to eventually working with other MS office formats, how about secretary?

rosie from "Rosie, the riveter"
riveters - rivete-rs, logo: r}ivet{s
galvanize-rs
or
schrute - from  Dwight scrute in "The office"

Or maybe rs-office as a reference to ms-office

What about "excel" or "xlsx"? Does the crate name need to be a pun or use "rs"?

Just to contribute to the bikeshed, I'd like to +1 the crate name "excel" and the github name 'excel-rs". It makes it obvious what it is/what it does.

What if somebody submits a PR to support opendocument format (.ods) used in libreoffice. Certainly it's not just excel anymore. The name should be something that pertains to spreadsheets, workbook, worksheets.

@ivanceras sheet / sheet-rs ?

@ivanceras: Not if @tafia doesn't plan on taking the project in that direction.

Thank you all for your comments!! I am very happy to see people willing to brainstorm on it.
I really don't want to be offensive, rude, diminish your participation or whatever but I couldn't find a single name out of your propositions.
Let me explain:

excel:  I prefer avoiding excel in the name for two main reasons:

I don't want people to assume there is any link with Microsoft. I'd prefer avoiding brands as much as possible (not to repeat the mistake with the current name). I will rely on tags in crates.io for people searching for an excel reader
As @ivanceras mentioned, while I have no immediate plan of implementing other format (there is still a lot to do to refine excel support), I'd like to keep the door opened, either for me or for any contributor
discards excel, excellerator, excel-reader, excel_file_reader,

xls, xlsr, xlrs, xlsx:

xls is probably the best choice here, as it looks more generic. It took me some time to understand that js-xlsx implemented all excel files. I suppose the name was picked when the development focus was on xlsx files (simplest to implement as you don't need the specs to start)
on the other hand, as for the previous point, it is too close to excel (it would be fantastic to have a odt support someday)

rivets, riveters, rivet-rs: I like rivets a lot but as @brianp mentioned there is a fairly big js project with that name and it will probably be confusing. As for riveters, it "sounds" not nice to me (I'm not English speaker so I may have the accent wrong in my head)
rs-office: I like this but I want to restrict the scope to sheets processing for the moment.
sheets, sheet-rs: This is too close to sheetjs IMO, and while I confess having cheated a lot with their code I have no direct relation with them. Would they want to have their own rust implementation, I feel like they deserve that name more than me
secretary: I like this one, but as for office or rs-office, this has a too broad meaning
rosie, schrute: I am not familiar with those ...
galvan: I love the link between sheets and rust .... but it prevents rust!

... no I have no more candidates! I am probably too strict but
I have a new contender. Looking at the french wikipedia page for galvanization (which is strangely much more detailed than the english version), I found that calamine prevents galvanization!
I like this name as it reminds me my childhood and, like galvan, as a link between sheets and rust.
Except if someone really dislikes it, I will probably pick on this one.

Thanks everyone for your time! calamine crate has now been published. :tada:
I don't feel really well about the totalitarian naming but I hope you'll understand my reasons.


[fastgltf] Update to 0.6.0

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[x] The "supports" clause reflects platforms that may be fixed by this new version
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Please get failure logs here:
Run Build Command(s): /usr/local/bin/ninja -v -v -j13 install
[1/4] /Library/Developer/CommandLineTools/usr/bin/c++ -DFASTGLTF_ENABLE_DEPRECATED_EXT=0 -DFASTGLTF_USE_CUSTOM_SMALLVECTOR=0 -DSIMDJSON_THREADS_ENABLED=1 -I/Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/include -isystem /Users/vagrant/Data/installed/x64-osx/include -fPIC -g -std=gnu++17 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -MD -MT CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o -MF CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o.d -o CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o -c /Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/src/fastgltf.cpp
FAILED: CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o
/Library/Developer/CommandLineTools/usr/bin/c++ -DFASTGLTF_ENABLE_DEPRECATED_EXT=0 -DFASTGLTF_USE_CUSTOM_SMALLVECTOR=0 -DSIMDJSON_THREADS_ENABLED=1 -I/Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/include -isystem /Users/vagrant/Data/installed/x64-osx/include -fPIC -g -std=gnu++17 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -MD -MT CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o -MF CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o.d -o CMakeFiles/fastgltf.dir/src/fastgltf.cpp.o -c /Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/src/fastgltf.cpp
In file included from /Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/src/fastgltf.cpp:55:
In file included from /Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/include/fastgltf/parser.hpp:32:
/Users/vagrant/Data/buildtrees/fastgltf/src/v0.6.0-ea6ba6bf5e.clean/include/fastgltf/types.hpp:34:10: fatal error: 'memory_resource' file not found
#include <memory_resource>
         ^~~~~~~~~~~~~~~~~
1 error generated.

Note: I will be converting your PR to draft status. When you're ready, please revert to "ready for review".

The usage test passed on x64-windows (header files found):
fastgltf provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(fastgltf CONFIG REQUIRED)
  target_link_libraries(main PRIVATE fastgltf::fastgltf)


Can't pair. 3rd party remote.

I think I've got a 3rd party remote. It came off ebay, from china. I don't have a real one to compare though.
When I try to pair it asks for the PIN code. Happy to supply any more info.
Using bluez 4.96-3 package.
Tried pairing with bluez-simple-agent and blueman.
Always using the red sync button.
$ grep wiimote $(which bluetoothd)
Binary file /usr/sbin/bluetoothd matches
$ cat /var/lib/bluetooth/00:15:83:3D:0A:57/did
00:11:67:00:21:ED 0001 0039 13A4 0310
00:06:F7:54:F9:AB FFFF 054C 0268 0000
00:25:D0:FA:BB:B4 0001 0001 0089 0000
00:11:67:00:00:0E 0001 0039 13A4 0310
00:18:00:42:80:74 FFFF 0000 0000 0000
$ bt-adapter -d
Searching...
[00:18:00:42:80:74]
Name: Nintendo RVL-CNT-01
Alias: Nintendo RVL-CNT-01
Address: 00:18:00:42:80:74
Icon: input-gaming
Class: 0x2504
LegacyPairing: 1
Paired: 0
RSSI: -80
Done

Ouh, this is awful. Your Wii Remote seems to have no DID information. Could you run:
sdptool search --bdaddr 00:18:00:42:80:74 DID
Normally this line 00:18:00:42:80:74 FFFF 0000 0000 0000 should say something more than 0000. The wiimote plugin detects the Wii Remote by its DID and if none is provided we would need some hack to detect it by name.
Do you have any idea whether the Wii Remote is from Nintendo? Or do you know the 3rd party vendor of the device? This would help a lot to create a whitelist or to get some more information about the device.
Also, do you know how to compile bluez yourself? I could provide you a patch to make the wiimote plugin work by detecting the devices by name.
Regards
David

hi,
same problem here as the original poster.
If you provide a patch I am happy to compile bluez
cat /var/lib/bluetooth/00:17:F2:AF:F8:5F/did
00:21:BD:17:A5:13 FFFF 0000 0000 0000
sdptool search --bdaddr 00:21:BD:17:A5:13 DID
Searching for DID on 00:21:BD:17:A5:13 ...
Service RecHandle: 0x10001
Service Class ID List:
"PnP Information" (0x1200)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Profile Descriptor List:
"PnP Information" (0x1200)
Version: 0x0100
what I have done is:
hcitool scan  (push the red button on the back of the wiimote)
it shows 00:21:BD:17:A5:13
then
bluez-simple-agent hci0 00:21:BD:17:A5:13
it asks for a pin
bluez 4.96-3 [installed]
all packages up-to-date

@casacristo Do you also have a non-standard Wii Remote? Or is this definitely an official Nintendo Wii Remote?
On top of bluez-git you need the following two patches:

[PATCH 1/2]: Fix wiimote device_get_address to use new API
[PATCH 2/2]: Detect Wii Remotes by device name

The first patch fixes a bug in current bluez-git which is not yet applied and the second patch is the actual patch for this issue.
Regards
David

My remote has the following engraved near the nunchuk plug:
RVL-003
MADE IN CHINA
and under the battery cover:
B7EF330
Nintendo
I will compile bluez-git and report back. Thanks!

ok, looks like it works:
Release
New device (/org/bluez/782/hci0/dev/dev_00_21_BD_17_A5_13)
bluez-test-device list
00:21:BD:17:A5:13 Nintendo RVL-CNT-01
But I am a bit lost now as to what to do next to actually get it to do something.
I thought I would get some sort of key presses on the terminal when I press the wiimote buttons but nothing seems to happen

Thanks for testing the patch. I will see whether I can get it upstream.
Regarding the Wii Remote input: Current development focused on the kernel driver. The next steps will be writing mouse/keyboard emulations based on the driver. It will take some time, though.
However, if your X-Server supports input-hotplugging you should be able to at least use the D-Pad as UP/DOWN/LEFT/RIGHT keys.

No other info on ebay page, but definitely just a chinese knockoff.
If you're still interested:
$ sdptool search --bdaddr 00:18:00:42:80:74 DID
Searching for DID on 00:18:00:42:80:74 ...
Service RecHandle: 0x10001
Service Class ID List:
"PnP Information" (0x1200)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Profile Descriptor List:
"PnP Information" (0x1200)
Version: 0x0100

Hi, I have the same problem. My device is a Wii Remote Plus bought on amazon and seems 100% original.
I applied PATCH 2/2 to bluez 4.98 (ubuntu precise package source) and it works.
News on getting this upstream?


Mop and water function for Roborock S7

Device model / 设备型号
roborock.vacuum.a15
Component version / 插件版本
0.7.3
HA core version / HA版本
2022.12.8
Integrated mode / 集成方式
Token
The problem / 问题详情
I use Roborock S7 in integration, it also has a control for mopping, it is possible to set the friction force of the rag and the amount of water supplied to the rag.
Is this ability to control the mop expected in future updates?
Or maybe you can help me add this feature via YAML.
Entity attributes / 实体属性
fan_speed_list:
  - Silent
  - Standard
  - Medium
  - Turbo
battery_level: 100
battery_icon: mdi:battery-charging-100
fan_speed: Standard
status: Charging
timers:
  - enabled: false
    cron: 0 8 * * 0,1,2,3,4,5,6
    next_schedule: '2022-12-25T02:00:00+00:00'
  - enabled: false
    cron: 59 23 * * 0,1,2,3,4,5,6
    next_schedule: '2022-12-24T17:59:00+00:00'
friendly_name: Xiaomi Roborock S7
supported_features: 14204

Home Assistant Logs / 系统日志
No response

Doesn't look like it from https://home.miot-spec.com/s/roborock.vacuum.a15
Can you grab the logs using Vevs Mi app to see which siid and piid is used to set those options from the app?

https://home.miot-spec.com/s/roborock.vacuum.a15

Yes it is https://home.miot-spec.com/s/roborock.vacuum.a15
I can install the Vevs Mi app for myself. Just tell me how can I get the magazines? Where should they be seen?

Install https://www.vevs.me/2017/11/mi-home.html
follow to activate custom logging https://github.com/al-one/hass-xiaomi-miot/issues/114#issuecomment-868721912

@VladimirTuzovGitHub  Your entity attributes does not appear to be integrated by this component.

@VladimirTuzovGitHub Атрибуты вашего объекта, похоже, не интегрированы этим компонентом.

Can I fix it? Or maybe you can fix it in future updates.


Fix dockerfile

@lukasmalkmus I'm so sorry! I just noticed that we can't run it as nonroot!
2023-08-10T13:54:16.212 app[91857559c17998] nrt [info] {"level":"info","ts":1691675656.2120683,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:71","msg":"starting","release":"0.6.0","revision":"edef102","build_date":"2023-08-09T11:41:52Z","build_user":"goreleaser","go_version":"go1.20.7"}

2023-08-10T13:54:16.212 app[91857559c17998] nrt [info] {"level":"info","ts":1691675656.2124286,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:106","msg":"started"}

2023-08-10T13:54:16.212 app[91857559c17998] nrt [info] {"level":"error","ts":1691675656.2128325,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:113","msg":"create server","error":"listen tcp :601: bind: permission denied"}

2023-08-10T13:54:16.213 app[91857559c17998] nrt [info] {"level":"warn","ts":1691675656.2129228,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:60","msg":"stopped"}

This affects all users using latest, so I think it needs a quick release!

I deployed with the exact same image I fixed, and it works as expected. The last time I tested it, I overlooked this issue because I used a multistage build to run the application in a slightly different setup from this repository.
2023-08-10T13:59:45.417 app[91857559c17998] nrt [info] 2023/08/10 13:59:45 listening on [fdaa:2:1571:a7b:17c:5275:2a9c:2]:22 (DNS: [fdaa::3]:53)

2023-08-10T13:59:45.436 app[91857559c17998] nrt [info] {"level":"info","ts":1691675985.4362023,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:71","msg":"starting","release":"0.6.0","revision":"edef102","build_date":"2023-08-09T11:41:52Z","build_user":"goreleaser","go_version":"go1.20.7"}

2023-08-10T13:59:45.436 app[91857559c17998] nrt [info] {"level":"info","ts":1691675985.4365556,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:106","msg":"started"}

2023-08-10T13:59:45.437 app[91857559c17998] nrt [info] [13:59:45.43] info axiom-syslog-proxy@logs/input udp.go:18 Started UDP server on udp:[::]:514

2023-08-10T13:59:45.437 app[91857559c17998] nrt [info] [13:59:45.43] info axiom-syslog-proxy@logs/input tcp.go:23 Started TCP server on tcp:[::]:601

2023-08-10T14:00:46.215 app[91857559c17998] nrt [info] 2023/08/10 14:00:46 ingested 1 event(s)

Argh, damit. But happens to the best.
We are still pre v1.0.0 so let's merge this, release v0.6.1 and call it a day :)

Yeah, that sounds good to me. It's good to see that the image size is now under 10MB, resource efficiency is improved, and the security holes that can be attacked are much smaller.

I can confirm again that it's working correctly! Thank you so much for the release!


Getting Started with Dogecoin Development - Need Guidance, Documentation, and Testnet Information

I'm a Golang software developer, and my supervisor has assigned me a task to work with Dogecoin. However, I have little to no experience with it, and I feel lost. I'm seeking guidance on how to get started with Dogecoin development.
Here are a few questions and areas where I need assistance:

Golang Packages: Could you please recommend a reliable Golang package on GitHub that I can use for Dogecoin development?

Connecting to a Node: I would appreciate it if you could suggest a free-to-use Dogecoin node that I can connect to. Additionally, please provide instructions on how to establish a connection with the node.

Basic Demo: It would be extremely helpful if you could provide a simple demo or point me to a beginner-friendly tutorial that demonstrates basic Dogecoin functionality using Golang.

Documentation: Is there any official or comprehensive documentation available that covers Dogecoin development with Golang? I would greatly benefit from a resource that explains the various APIs, functionalities, and best practices.

Testnet: Does Dogecoin have a testnet (test network) available for development and testing purposes? If yes, please provide instructions on how to connect to the Dogecoin testnet and any additional details I should know.

I'm eager to learn and contribute effectively to the Dogecoin project. Any guidance, documentation, or resources you can provide would be greatly appreciated.
Thank you in advance for your help!
Best regards.

My code can not work. I don't know the reason.
package main

import (
	"github.com/btcsuite/btcd/rpcclient"
)

func main() {
	cfg := &rpcclient.ConnConfig{
		Host:         "rpc.dogecoin.com", // 第三方 DOGE币节点的RPC地址
		User:         "",                 // 留空或设置为一个空字符串
		Pass:         "",                 // 留空或设置为一个空字符串
		DisableTLS:   true,               // DOGE币节点默认不使用TLS
		HTTPPostMode: true,               // DOGE币节点只支持HTTP POST模式
	}
	client, err := rpcclient.New(cfg, nil)
	if err != nil{
		panic(err)
	}

	err = client.Ping()
	if err != nil{
		panic(err)
	}
}


How to use import/named to detect non-existent imports from monorepo packages?

Of course, using TypeScript can avoid the need for this - but for modules that are still JS-only, how can we detect instances of importing named exports which don't exist?
The docs seem to suggest that if the module you're importing from either uses import or export then it should work - or maybe if it defines a module field in package.json - but none of these seem to work and imports of non-existent names are not flagged.
It also mentions:

Redux's npm module includes this key, and thereby is lintable, for example.

But this doesn't appear to be the case. I even tried manually specifying jsnext:main in the package.json but no difference.
I also tried with our monorepo's packages folder included under import/external-module-folders or not; again, no difference.
Is this the intended behavior?

The rules in this plugin should already be able to handle it, with no TS involved at all. Note that some rules require being configured with commonjs: true to detect things from CJS.

Thanks so much for your speedy reply @ljharb!
I noticed a few minutes ago that it did flag for missing imports from one package; but from several of ours it will not. I'm not sure what the common thread is there. None of the modules causing problems are using CommonJS.

So if foo imports from bar imports from baz:
Works:
Importing a non-existent name from baz into bar is flagged
Importing a non-existent name from baz into foo is flagged
Fails:
Importing a non-existent name from bar into foo is not flagged

But there's no other .eslintrc files interfering, not a trace of CommonJS, and the issue persists even if I change the problem module to simply contain export {}
That's the same module I tried those other workarounds for like putting module or jsnext:main into the package.json without luck.
We have 'import/cache': { lifetime: 0 }.
The package is not involved in any import cycles.
Is there anything else I could be overlooking?
Even if I can't get it fixed, I'd love to determine why it fails so I can understand when I might not be able to trust that rule.

@ljharb any other thoughts on this problem?


WIP add .lens syntax to Lens and Prism

Add lens extension methods to all optics such that we can use .lens(_.foo) instead of composeLens GenLens[Target](_.foo)

@yilinwei do you know if it is possible to generalise the implementation so that we don't need to duplicate the macro for each optic type?

@julien-truffaut
Yes there should be; did you try returning a c.Expr[Any] and invoking the same impl with a narrowed type?
If that doesn't work, we can also do an inline method and invoke the macro which should definitely work (you'll need to do a .cast with the Expr, but that's safe because it still does a typecheck before embedding the tree.

closing, for now, let's review when we have the Focus macro


Datagrid: Row detail doesn't span last column when using row selection (without control)

Have a grid with multiple columns, using row selection (without the controls) and row detail.
Observe that the colspan for the row detail is 1 less than it should be.

Fixed in v0.8.3


Known/Reserved words in config

Clear and concise description of the problem
Could typespec give a way to define the known/reserved words for a spec, which could help emitter to do renaming or give participle more correctly? Maybe a config in tspconfig?
Checklist

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Can you explain a little more what you mean here?

For example, if a property name is storageThroughputMBps, we want the snake case name to be storage_throughput_mbps instead of storage_throughput_m_bps which needs MBps to be a reserved word.

There is work in a new separate codegen framework to include a powerful naming functionality. I would delegate to this when it is ready. For TypeSpec compiler itself I think for those edge cases you can always use @clientName for now


Prepared Containerfile

Hi @berendt,
i've prepared the Tang Containerfile
please take  a look here https://github.com/matfechner/container-image-tang

@matfechner LGTM. Can you prepare a PR for this repository? I will create the required Quay repository + add the secrets to this repository.

Hi @berendt,
thanks,
please open an initial commit for this repository, then i will create PR

@matfechner Done.

after merge it is done


Hpx serialization

Some inconsistent stuff still exists. Mostly it's related to polymorphic serialization because current polymorphic serialization mechanism(intrusive and nonintrusive) has to be refined.

A couple of observations:

tests/performance/local/serialization_overhead_master.cpp is missing (the build system refers to it)
several files are in hpx/util, but contain code which is in hpx::serialization - will that be changed?
util/serialize_buffer.hpp (and other files related to serialization), code is currently in hpx::util - will/should that be moved?
components/remote_object and components/vector have not been ported to new serialization yet
there is a lot of debug output being generated while serialization (but hello_world seems to run)

Is there a way to tell if an Archive type is an archive, and whether it's an input or output one? Or some other way to implement serialization support without ever including a single bit of the serialization library itself?

Nitpick: the placement of braces after namespace is inconsistent across this PR. The dominant style within existing code is:
namespace hpx { namespace whatever // newline
{ // opening brace

I don't think this is explicitly stated anywhere, so I'd appreciate if others would chime in.

Some save/load interfaces use input/output_archive as argument, others use a template argument (which I'd rather see renamed to something other than just T). What's the guideline here, when should I pick one or the other?

@K-ballo I everywhere tried to use template  instead of just template . I think, no guidelines on templated/nontemplated versions are there. It's just easier for user to have Boost.Serialization compatible interface. We can stick to one way inside HPX, though.

Is there a way to tell if an Archive type is an archive, and whether it's an input or output one? Or some other way to implement serialization support without ever including a single bit of the serialization library itself?

I don't see any, if I understand you correctly.

Is there a way to tell if an Archive type is an archive, and whether it's an input or output one? Or some other way to implement serialization support without ever including a single bit of the serialization library itself?

I don't see any, if I understand you correctly.

Would it make sense to introduce special traits for this? @K-ballo: I'm not sure what you have in mind, but wouldn't traits handle your use case?

Would it make sense to introduce special traits for this? @K-ballo: I'm not sure what you have in mind, but wouldn't traits handle your use case?

Traits would still require including some library code in order to support serialization. With Boost.Serialization, it is sometimes possible to implement serialize SFINAEd on Archive::is_saving, and thus does not require including anything extra. The existing of the is_saving member is interpreted as Archive modeling the Archive concept, and the save/load split can be done based on its value. This was likely just by chance for Boost.Serialization, but I would really like to see some similar way of adding serialization support without actually introducing a hard dependency nor a single extra #include.

Looks good to me! I think we should merge the changes as soon as possible now.

Merging this will help with development of parcelport code which depends heavily on serialization.


Create a 'shared resources' page

This is where I'll have links to my:

CV
Head Shot (PNG)
Head Shot (Purple BG)
Other
Short Description

Similar to this:
https://emmawedekind.com/resume-templates
And this:
https://kentcdodds.com/info/


Update TAP reporter. fix #2410

Updates the TAP reporter to print the describe blocks as diagnostic messages to allow for proper TAP output.

Each failure appears to be an issue with PhantomJS not installing correctly. Not sure how to remedy this

Did the behavior of the reporter also change from a streaming output to a buffer that is only flushed at the end?

Yeah, it's not clear to me why we're buffering things now... @apkiernan ?

Apologies for the delay in responding, started a new job recently.
Looking back at this I think I had originally made the buffering change for testing purposes. I noticed the reassignment of console.log in another test and made the change to these tests as well so the buffering isn't needed. This has been changed back to streaming the output as it was originally.

Looks good to me.
I'm a bit confused about not seeing any tap reporter test output in the CI log. I'll see if I can have a look into that. Wouldn't want the tests to somehow not be run, now that we have them :)