TypeScript bug -  Create message request returns bad request error

Testing code:
const userRequestBuilder = client.usersById("ID");
const messagesRequestBuilder = userRequestBuilder.messages;
const message = new Message();
message.subject = "test subject";
const post = await messagesRequestBuilder.post(message);

thanks for reporting that.
I had a quick look into this, the URL and the serialization seem fine.
However, this seems to tie in the discussion we were having in #665
Adding the following "workaround" in fetchRequestAdapter.getRequestFromRequestInformation makes it work (by changing from a readable stream to a string). Obviously this is not a long term fix
let content = undefined;
        if(requestInfo.content) {
            const serializationResult = requestInfo.content as unknown as ReadableStream<Uint8Array>;
            const reader = serializationResult.getReader();
            const decoder = new TextDecoder();
            const buffer = await reader.read();
            content = decoder.decode(buffer.value);
        }

application/json expects a stringified object.
The content can be of multiple types such as Blob, FormData, string, object(in case of axios). These types are not compatible or interchangeable with ReadableStream.
As per fetch,  body data type must match "Content-Type" header
The user should be able to set content with data type of their choice. The fix for this problem is to update the type of content and allow variable data types.
Examples of possible content-types:
BodyInit: Blob | BufferSource | FormData | URLSearchParams | string;
https://github.com/microsoft/TypeScript/blob/main/lib/lib.dom.d.ts
export type BodyInit = 	| Blob 	| Buffer 	| URLSearchParams 	| FormData 	| NodeJS.ReadableStream 	| string;
-https://github.com/node-fetch/node-fetch/blob/main/%40types/index.d.ts
export type BodyInit =   | ArrayBuffer   | AsyncIterable<Uint8Array>   | Blob   | FormData   | Iterable<Uint8Array>   | NodeJS.ArrayBufferView   | URLSearchParams   | null   | string
https://github.com/nodejs/undici/blob/main/types/fetch.d.ts

The serialization writer could return WhateverStreamTypeWeLandOn | string, and the content could be of the same type in request information.
I'm a bit reluctant to do that because we're pushing and http library constraint onto the abstractions and serialization, but at this point I don't see any other alternative except the "workaround" I posted in my previous comment.
Obviously, since the json serialization writer is already using a string array internally to build the json payload, concatenating it and returning it as a string, doing the exact opposite operation in the caller (request adapter) would be bad for performance.
Thoughts?

If we were to make RequestInformation.Content a Blob then I think we can have a uniform interface because Blob can be initialized with either a string or an ArrayBuffer and you can provide a contentType in the Blob that gets transfered to the contentType header in the fetch request..
Then you just call it like this:
        var content = ['[1,2,3]'];
        var options = { type : 'application/json' };
        var request = new Request("https://httpbin.org/anything", {
            body : new Blob(content, options),
            method : "POST"
         });
        fetch(request)
            .then(response => {
                console.log(response);
                console.log(response.body);
            });

Blobs are not present in Node.JS. Will blobs work with ReadableStream?
Why do we need to specify a type for content?
The http libraries such as Fetch, Axios support multiple data types for the content and each library has its own way of handling the request body and request configurations.
[interface AxiosRequestConfig<Data= any>] (https://github.com/axios/axios/blob/6b4fd93e6886c281ef1a51fca556616ce17f8fba/index.d.ts#L62) <- The request body is of any type is Axios.
Example, for content-type application/json fetch expects a JSON object to be stringified while axios expects the JSON object and not the stringified version. axios treats a stringified JSON as application/www-x-form-urlencoded.
I strongly feel that we should use a generic content type or TS.any.

A generic type or any type avoids the pain of managing a Node/browser data type for the content.

Say if we are using the JSON serialization library, we can simply return the JSON object, set this in RequestInformation.content and the Kiota-http library will set this JSON object in the request body as per the JS http library that is being used. We can avoid the two step process of reading to and from a defined data type content.

As each http library has its own way of handling the request body and request configurations, a defined type could be handled unexpectedly in some http library causing errors.

JS http libraries accept a wide range of content data types.

Focusing on the ease of use of the Kiota libraries for the customers. Managing content conversion and compatibility should not add to the learning curve.

Using any is an easy way out of this for us, but it feels like kicking the can down the road.
Instead of getting compile time validation, people will have to go all the way to runtime and check that things work for them.
Should they be passing the wrong thing, the only way they'd know is if they dive into our code and/or if we do a great job at documenting what this is expecting. I'm not sure how that will "improve" their experience?
Should we end up choosing that path, I'd argue to use unknown instead of any so we get some level of compile time validation.
Expanding on the blob alternative:

Blob ctor is available for 98% of browsers today
Blob on nodeJS is experimental since node 15 which would require using a polyfill/library

The opportunity here using a polyfill is that we'd have alignment.

Why is what Axios does a factor for us?

@darrelmiller
Axios, fetch are popular http libraries in JavaScript. My assumption is a Kiota user can bring in their choice of library. So in that case, a user could have their own Kiota-http implementation with axios. Or are we supporting only fetch?

Should we end up choosing that path, I'd argue to use unknown instead of any so we get some level of compile time validation.

I am fine with unknown too. Basically, my point is that allow the flexibility to pass content types, avoid the complexity of compatibility and conversions and take into account that multiple content-types are supported by the popular http libraries.
Conversion from certain types to a Blob might not be convenient. FormData to Blob conversion is an example I can think of at this.  My concern is that this could be a blocker if there is a content-type that cannot be converted to Blob.
The fetch-blob polyfill uses the webstreams-polyfill which is bulky.

Should they be passing the wrong thing, the only way they'd know is if they dive into our code and/or if we do a great job at documenting what this is expecting. I'm not sure how that will "improve" their experience?

My preference is:

Saving runtime efforts in managing the conversions. I prefer smoother runtime than compile time issues.
I get the advantage of having a strict type during compile time. However, I am concerned about the extra steps users will have to take to research and convert the data-types. Also, the conversion between types should not be a blocker. Adding a strict compile time will not ease things up for a user.

I thing we're operating off different assumptions here: my assumption has been that we're building a TypeScript library first that happens to work for JavaScript users since TypeScript is a superset.
The advantage of using TypeScript over JavaScript is mostly the strict type compile validation, which allows the developer to catch issues early on, rather than failing at runtime.
This is why I've been pushing back on empty interfaces/any/unknown as it kind of defeats the point.
Besides these options I think we've identified two alternatives this far in the multiple discussion, that are not necessarily opposite:

delegating the compatibility work to polyfills and isomorphic libraries
handling it ourselves through variants

It's a build or buy situation, and building gives us more control over buying, which we might need as we're shipping libraries and not final solutions as you mentioned earlier.
I'm ok with going with variants as long as we don't duplicate too much code as we discussed in one of the PRs.
Now, for the stream aspect, the impact is larger than just the abstractions/serialization/http libraries, any endpoint that takes or returns a binary payload will need to need to expose a stream type to the consumer. And I don't think starting to generate variants for the service libraries will be a sane exercise.
Since the service lib will require a polifyll (unless you can suggest a better alternative that doesn't rely on unknown/any/empty interfaces), couldn't we leverage the same polyfill for the requestInformation content property? (and do the variant work for the http fetch and serialization libraries)

My assumption is a Kiota user can bring in their choice of library.

Our first priority is to create SDK tooling that can make HTTP requests to any OpenAPI described API.  We have created an abstraction to allow people to replace our core library with theirs if they wish.  The goal is not to enable Kiota to work with any HTTP library as a drop-in replacement.  It's a subtle difference, but when the desire to support some 3rd party library is holding  us back from our primary goal, then my opinion is that we put the burden of work on the person who wants to replace our default core library.  People build HTTP libraries on top of Fetch to make it easier to make HTTP calls.  Our Kiota service libraries are designed to make HTTP mostly go away.  The value of things like Axios largely goes away when you bury it inside a Kiota service library.

I agree with @darrelmiller that allowing people to replace HTTP library shouldn't be our first priority. As we're abstracting away issuing HTTP requests, it shouldn't be relevant which library we use internally, as long as we support whatever configuration options and capabilities our developers need.
Requiring developers to wrap the request body in a Blob feels awkward. Since the body can be (almost) anything, we should abstract away the intricacies of handling the different types (stream vs. JS object vs. plain text) into our SDK and let developers just set the payload they want to include in the request. If there are specific edge cases, we could consider offering developers an ability to override our default behavior, but we should strive to create an SDK that developers can use without ceremony or intricacies.

Since the body can be (almost) anything, we should abstract away the intricacies of handling the different types (stream vs. JS object vs. plain text) into our SDK and let developers just set the payload they want to include in the request

@waldekmastykarz How do you think this can be achieved?

I agree with @waldekmastykarz that having to wrap request body in a Blob (or actually... any type really) is awkward... Even if we think about type safety, this wouldn't make it work any better as you'd get an ArrayBuffer or a Blob, but this doesn't confirm anything "valid" as part of the payload. The fact that developers are used with the following notation makes me think we should be staying as close as possible to what they would be expecting :
JSON.stringify({
    'prop': 'value'
});

Or going an extra step with a Generic type? That way I can let the caller let the library know of the type <D = any> but you get some compile time advantage?

@nikithauc if I'm not mistaken, it's implemented that way in Axios. You can set its body to anything, and Axios will take care of it properly calling the API. If we can achieve the same in our SDKs, it would be a great step towards making them easy to use.

@waldekmastykarz I think we need to be precise in our discussions when we talk about "the SDKs" here, because this lack of precision leads to a lot of confusion. There are two aspects of the SDKs:

a generic HTTP client, with a bunch of middleware to make your life easier (but no types, no fluent style API, etc...): this has traditionally been handled by core libraries in other languages, this is the JS SDK today. This is not what kiota is trying to build.
a fluent style API SDK, with models, building on top of the middleware functionalities of the core SDK. This is what Kiota is focused on.

In both cases, the middleware infrastructure will make assumptions about the underlying client, and allowing to drop-in replace the underlying client has never been a goal for any of those SDK "types". We, the Microsoft Graph SDKs team, made a decision for the client, or at least what the client should support. Either that works for the customer or they can replace some of the default implementations we provide while keeping other aspects we provided (more on that below).
Now, citing Axios way of doing things as an example for Kiota fluent SDKs is almost irrelevant, because this is not what we're trying to accomplish here as @darrelmiller mentioned in his earlier comment.
Kiota honors a few architectural principles including a decorrelation between the generated SDK and the HTTP/serialization/authentication implementations, as well as no interdependencies between those layers.
For that reason @sebastienlevert using JSON.stringify on Kiota models from a JSON payload was never intended to work. Customers will have to use the serialization writer and the deserializer we provide with the models. We've had so many issues in the past in dotnet and java trying to using general purpose serializers (Gson, system.text.json, newtonsoft.json...) and twisting their arms to account for OData conventions. This is why we decided with Kiota to go the auto-serialization way instead as the OpenAPI description already gives us all the information we need to handle that aspect properly relying on code-gen. (or it will once we're done fixing some issues with the conversion process).
All of this doesn't mean we cannot have both a core library for generic requests and a fluent style library for our API surface relying on a common code-base for authentication and other aspects.
Bottom line, if we focus on the request body type, which I believe is the core of this issue, Nikitha already started putting together a PR to address that see #992. The approach is to use ArrayBuffers, which our serializers will be using with that PR. This means we're taking limited responsibility for polymorphism (defaulting to the only common type, no dependency on a third party). The only drawback of that approach is for binary uploads where the whole file will be loaded in memory, which will lead to memory pressure for large files.

Let's check if we're looking at things the same way...
The reason I brought up Axios is because we're discussing how we'd expose building requests to developers. Axios was nothing more than an example of what I think is a developer-friendly way of building requests. If our decision is to not expose building requests to developers, then the whole discussion is indeed irrelevant, because how we implement building requests internally is relevant only to us. But if we see a valid use case for developers to have to build their own requests when using our SDKs, then I'd advocate for making it as simple as possible, just like it's possible in Axios (but not based on Axios, so a pattern rather than technology), and not force developers to have to wrap each payload into an arbitrary object that's specific to our SDKs.
I hope this clarifies it. I appreciate the conversation.

This does, and I think this conversation is relevant in the context of the JavaScript SDK, but not necessarily in the context of kiota (although some outcomes of that discussion might impact the work in kiota).
Kiota never promised being able to make arbitrary requests, for that purpose people can use whatever native client they prefer. And if that client matches the requirements of our middleware infrastructure, which means they can re-use our middleware for arbitrary requests, perfect.
If you look at the Go SDK today (which is the most Kiota-based SDK, no historical past), you'll see it doesn't provide a way to make arbitrary requests itself. The only thing it provides is a way to use the same middleware a kiota/graph fluent-style client uses with a native client.

Sounds like we got it covered now! ArrayBuffer it is! This should unblock us for and allows for building the JS SDK!

if we see a valid use case for developers to have to build their own requests when using our SDKs, then I'd advocate for making it as simple as possible, just like it's possible in Axios (but not based on Axios, so a pattern rather than technology), and not force developers to have to wrap each payload into an arbitrary object that's specific to our SDKs.

I agree with @waldekmastykarz
ArrayBuffer unblocks us for now but I believe the solution will add an overload for developers (who use kiota to build their library) to wrap a wide range of payloads with in the arraybuffer or a fixed data-type.
JS SDKs run in a node and browser environment. Both the environments are distinct in some ways with their own features and apis. There are a wide range of http libraries in JS  each of which have their own way of parsing and serializing the payload and making the final request to the server depending on the environment.
So basically, Kiota will be serializing a payload to an array buffer and then the underlying http library will serialize the arraybuffer to a data type of their choice.
This adds a lot of complexity at run-time and could also add a curve in the developer-friendliness of Kiota.
Also, it reduces maintenance work and reuses the serialization which is provider by the underlying http library we use.
I agree that Kiota is not an http for making an arbitrary request . The point is how we are dealing with the dynamic nature that comes with JS ecosystem. In this case,  flexibly managing multiple payload types that can be variably serialized depending on the choice of the environment and http library.

ArrayBuffer unblocks us for now but I believe the solution will add an overload for developers (who use kiota to build their library) to wrap a wide range of payloads with in the arraybuffer or a fixed data-type.

At some point the different layers need to return a data type, defaulting to unknown, object or any is just making us lose compile time validation and doesn't provide additional value to the consumer. The polyfill approach had the advantage of offering flexibility to the consumer while not adding burden on us.

There are a wide range of http libraries in JS each of which have their own way of parsing and serializing the payload and making the final request to the server depending on the environment.

Is not a valid statement in our case since we already said that a drop in replace of the underlying HTTP lib is not a goal for Kiota, consumers can either use the http request adapter implement we provide with the lib we chose, or reimplement the interface.
A more accurate concern is, with the different platforms, the choice of http client we made has different behavior. Different behavior we can circumvent by: using poly/nyfills (my original approach), shipping variants (approach we explored), shipping different libraries all together (approach Azure has chosen).

This adds a lot of complexity at run-time and could also add a curve in the developer-friendliness of Kiota.

The only complexity added for developers is for file upload/downloads, everything else is encapsulated to them thanks to the fluent API. For that specific case however, we can perfectly ship utility methods in the variants to help go from a browser blob/nodejs file handle/etc... to the whatever type (union) we end up choosing and make their lives easier.

The only complexity added for developers is for file upload/downloads, everything else is encapsulated to them thanks to the fluent API. For that specific case however, we can perfectly ship utility methods in the variants to help go from a browser blob/nodejs file handle/etc... to the whatever type (union) we end up choosing and make their lives easier.

Am I reading this correctly, that developers using the SDK, will be able to call:
const message = {
    "subject":"Did you see last night's game?",
    "importance":"Low",
    "body":{
        "contentType":"HTML",
        "content":"They were <b>awesome</b>!"
    },
    "toRecipients":[
        {
            "emailAddress":{
<EMAIL_ADDRESS>            }
        }
    ]
};
client.me.messages.post(message);

without having to wrap the message in ArrayBuffer first?
Just to ensure that we're talking about the same: using ArrayBuffer is not the problem in itself, as long as we don't require developers to wrap all payloads in it. If we use ArrayBuffer, or anything else internally, that's our design decision.

almost
const message = new Message();
message.subject = "Did you see last night's game?";
message.importance = Importance.Low;
message.body = new ItemBody();
message.body.contentType = BodyType.HTML;
message.body.content = "They were <b>awesome</b>!";
const recipient = new Recipient();
recipient.emailAddress = new EmailAddress();
recipient.emailAddress.address =<EMAIL_ADDRESS>message.toRecipients = [
    recipient,
];
client.me.messages.post(message);

It's too bad that AFAIK TypeScript doesn't support a property initialization syntax like CSharp/Java/etc... because we then could do instead:
const message = new Message() {
     subject: "Did you see last night's game?",
     importance: Importance.Low,
     body: new ItemBody() {
          contentType: BodyType.HTML.
          content: "They were <b>awesome</b>!",
     },
     message.toRecipients = [
         new Recipient() {
             emailAddress: new EmailAddress() {
                    address<EMAIL_ADDRESS>             },
         },
     ],
};
client.me.messages.post(message);

Actually, just after writing this, I remember we could do that in TypeScript, maybe this is something we should consider adding to enable the (shorter) second style
https://stackoverflow.com/a/37682352/3808675

Definitely, this would add a lot of value here. But, why are we using classes vs Interfaces? Interfaces would allow us to achieve this. There is probably a reason behind this design, so if we can do the partial initializers, this would be a great start. But let's think in a "JavaScript / TypeScript" way and not in a non-familiar way for developers. If they never used new EmailAddress() in the past, I don't know if they should in the future, as long as they respect the interface...

because of the way the serialization works.
https://github.com/microsoft/kiota-samples/blob/763939eba29c9a13e9455d44f84abe76c0d44d3a/msgraph-mail/typescript/src/models/microsoft/graph/message.ts#L314
And also in anticipation with backing store.

created #1008

+1 to what @sebastienlevert said. new Message() doesn't seem like anything I've ever seen in JavaScript. It's intuitive in C#, but not in JavaScript. Rather than imposing a specific usage patterns on developers, we should see if there are other ways for us to implement necessary plumbing while allowing developers to use programming patterns they're used to.

Creating a separate issue #1013 to discuss more about interfaces vs classes as this discussion is not related to this present issue.


Update README.md

Doesn't meet the high level of code quality needed to be merged into this repository.


Intermittent errors when running 11-error_default_type_spec.lua

Summary
We get intermittent errors when running the test suite on file 11-error_default_type_spec.lua. This is visible in the Travis-CI logs, which occasionally fail.
This is caused by the fact that these tests update the configuration, run kong reload, wait for an arbitrary amount of time, then run the test. This arbitrary amount of time (currently 0.5s) is not always enough.
Steps To Reproduce

Set up a local development environment
edit test 'spec/02-integration/05-proxy/11-error_default_type_spec.lualowering the value ofRELOAD_DELAYto a value that's too small, such as0.0001`
run test: busted -v ./spec/02-integration/05-proxy/11-error_default_type_spec.lua
tests will fail
edit test 'spec/02-integration/05-proxy/11-error_default_type_spec.lualowering the value ofRELOAD_DELAYto a value that's large, such as2`
re-run tests: busted -v ./spec/02-integration/05-proxy/11-error_default_type_spec.lua
tests will succeed

Closing as per the linked PR which addressed this unreliability by changing the paradigm around testing upstream error reporting!


Language selector does not always work with options + sortOrder

Originally posted by @olemartinorg in https://github.com/Altinn/app-frontend-react/issues/1614#issuecomment-1792446840
When testing #1614 against the reasons radio list in frontend-test and adding language keys for one of the options there, it seems that:

The options are sorted according to their text resource key, not the actual label (I set the key to something beginning with z, so it always came last, even though the text resource value started with a)
The options don't always change according to the changing language (when using the language selector). I assume that problem wasn't introduced in #1614

I think we should add a Cypress test for this scenario, and fix the underlying issues with it. 🙏
https://github.com/Altinn/app-frontend-react/assets/700139/cced6a00-c7fb-4a67-9f5c-7e7726ff9501

It seems like the language selector part is broken for the entire app, not just options + sortOrder.
I've fixed the issue of sortOptions being sorted by their text resource key, and not value in a separate issue here: #1634


Feature: modularize by overlay / simple

Coverage decreased (-0.5%) to 83.824% when pulling 0cb5cff0ef001f82db5ef1decf392754802b36f3 on feature--overlay-simple into daa24c6f3a36647d7489dea62977a50f170c8018 on master.


fix Flakiness

closes #180

See commit messages for explanations of the flakiness. The diffs should then be self-explanatory

This also looks good. :ship: :it:

There's one more flaky test I found that I want to fix first. I'll post an update after I take a look at it.

@StephHippo: updated. Here is the failure it fixes:
Scenario: Search by keyword in a course description
undefined method `split' for nil:NilClass (NoMethodError) ./features/step_definitions/course_explorer_steps.rb:60

Poke for update.
Really want to get this merged b/c re-running rake for flaky tests is driving me crazy.

:+1:


[$500] URL link does not show on left bottom side on hover

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

Action Performed:

click on FAB and select Request money
go to distance tab
click on Start
turn off location permission and click on use current location
hover on blue text (" allow location permission in settings ")

Expected Result:
should show redirection link on left bottom side
Actual Result:
does not show redirection link on left bottom side
Workaround:
unknown
Platforms:

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

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.79-3
Reproducible in staging?: y
Reproducible in production?: y
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
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/38435837/dae346b7-294c-47cb-9e30-7b33961748b0
https://github.com/Expensify/App/assets/38435837/59707ecd-d633-4724-b554-0a9693ccb229
Expensify/Expensify Issue URL:
Issue reported by: @gadhiyamanan
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1696570726241719
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~015a2e2ea2fec5b775
Upwork Job ID:<PHONE_NUMBER>001014272
Last Price Increase: 2023-10-06

Proposal
Please re-state the problem that we are trying to solve in this issue.

Link does not show on the left bottom side on hover

What is the root cause of that problem?

Currently, we do not have the href prop when using  <TextLink />, so when user hovers over the text, link does not show on the left bottom
https://github.com/Expensify/App/blob/f7ac3767704b6f01a501d5b036d7844a376266c9/src/components/LocationErrorMessage/BaseLocationErrorMessage.js#L46-L51

What changes do you think we should make in order to solve the problem?

Add the href prop to the above, like below:

     <TextLink ... href={CONST.NEWHELP_URL} >{` ${translate('location.allowPermission')} `}</TextLink>

What alternative solutions did you explore? (Optional)

NA

Result

Proposal
Please re-state the problem that we are trying to solve in this issue.
Link not shown on the left bottom side on hover
What is the root cause of that problem?
The element is span() not link()
What changes do you think we should make in order to solve the problem?

Change the element from span to  tag/ link
What alternative solutions did you explore? (Optional)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Proposal
[Updated] https://github.com/Expensify/App/issues/29002#issuecomment-1750856891

Not sure if this is really a bug, I don't see any real issue with the redirect link not appearing.

@DylanDylann's proposal LGTM - nice and simple fix!
:ribbon::eyes::ribbon: C+ reviewed


G Key is being triggered as Shift+G?

What code did you use?

V works but G requires shift for some reason

I can't reproduce. This probably has to do with your keyboard, OS, or Roblox. You could try using this place to see if you have the same problem.

Yep same problem

Try placing print("0", UserInputService:IsKeyDown(Enum.KeyCode.LeftShift)); in different parts of the code (change 0 to 1, 2, 3, etc).

See if it says you are holding Shift down when you aren't pressing anything.
See if it says you are holding Shift down when you are pressing G
See if it says you are holding Shift down when you are pressing V
See if it says you are holding Shift down when you are pressing Shift

It's def on my end, It works fine in game but studio test bugs


Style fixes broke the doxygen api doc generation

The style fixes in #14 broke doxygen api code documentation generation. Should be a quick fix of the doxygen config file.

Issue is now fixed and api docs have been uploaded for the RC1 version.


[AWS Cloudformation] Caution: password authentication isn't enabled by default

"Caution: password authentication isn't enabled by default". Can you activate the password per default and set it to the instance ID? You can get the instance id from the metadata. Take a look at the following link and just add instance-id at the end of the meta-data url. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#instance-metadata-ex-2

@gcarmin Where did you guys see this error?


SystemD.notify_ready when starting as follower

WHAT is this pull request doing?
Sends SystemD.notify_ready when starting LavinMQ as follower, so systemd knows the service has finished activating.
HOW can this pull request be tested?
Start LavinMQ as a service as a follower

Maybe SystemD.notify_ready should be before syncing files instead (i.e. after authenticate)? Depends on how we want to look at it I guess

Yes, after auth i would say
On Tue, 30 Jan 2024, 15:20 Viktor Erlingsson, @.***>
wrote:

Maybe SystemD.notify_ready should be before syncing files instead (i.e.
after authenticate)? Depends on how we want to look at it I guess
—
Reply to this email directly, view it on GitHub
https://github.com/cloudamqp/lavinmq/pull/626#issuecomment-1916972546,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABL6TTP6N5H7QOLYW4GMRDYRD6TTAVCNFSM6AAAAABCRKUGF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJWHE3TENJUGY
.
You are receiving this because your review was requested.Message ID:
@.***>

Sync can be called multiple times. Put it on top of follow instead

Sync can be called multiple times. Put it on top of follow instead

Yeah, that's probably better 👍


registry/rpc: use simpleBalancer instead of ClientConn.State()

As ClientConn.State() of gRPC has disappeared, we need to avoid using ClientConn.State(). Instead we should make use of gRPC rebalancer mechanism, just like etcdv3 is doing. To do that, introduce simpleBalancer, as a minimum structure to be used for grpc.Balancer.
Note that this change could be possibly invasive to the current behavior of fleet's gRPC. A careful review is needed.
/cc @hectorj2f
Fixes https://github.com/coreos/fleet/issues/1672

@dongsupark could add a bigger description about what the balancer does ?
Also, this PR is a bit big. What do you think about a PR for the vendoring packages and another with the logic ? That would make the reviewing much easier and faster.

@hectorj2f Sure, I will split it into multiple PRs, and add more descriptions.

Force-pushed it by changing the following:

Fixed bugs in IsRegistryReady(). This function still needs to check r.Status() like before. It also needs to check if r.registryConn or r.balancer is nil.
Fixed a bug in rpcAcquireLeadership() by inserting reg.IsRegistryReady() to the condition for checking existing lease. This bug resulted in another failure in TestDynamicClusterNewMemberUnitMigration(), which got me locked up in a debugging nightmare. (Now it's solved)
Simplified balancer.go, removing unnecessary parts like getHost().
Added high-level descriptions on simpleBalancer.

And I created 2 PRs, https://github.com/coreos/fleet/pull/1676 (only vendor updates) and https://github.com/coreos/fleet/pull/1677 (relevant code), for easier reviews.

FYI.
Running benchmarks with this PR included, I can observe performance regressions. Nomi benchmarks starting thousands of units over a multi-node cluster, unit starts take much longer time than the current master branch.
I'm not sure why. (gRPC balancer issue? Bug in my patches?)
Until we figured out its reason, let's not merge this PR.

Running benchmarks with this PR included, I can observe performance regressions. Nomi benchmarks starting thousands of units over a multi-node cluster, unit starts take much longer time than the current master branch.

I finally got some time to do nomi benchmarks again. This time, I cannot see the regression any more.
When tested with etcd v3, results of master branch and this branch are nearly the same.
With etcd v2, this branch is even faster than master.
That's actually an expected result, as it's already known that performance got improved with gRPC v1.0, compared to the previous versions.
What I saw in September was probably just a testing mistake.
Tomorrow I'll run again benchmarks several times, and if it's still green, I'll merge this PR.

I can confirm that its performance is all right.
With etcd2, unit start time was improved by 16%. With etcd3, it's nearly the same.
Benchmark raw data is available on https://github.com/dongsupark/fleet-benchmarks.
I'll merge this PR. Thanks!


DO NOT MERGE: Hacky updates to be able to preview prometheus/prometheus 3.0 migration doc changes

Hello, I tried to fix the issue.
This is what I did:
Updated the pull request template to include specific instructions for signing off commits with the DCO. Added a link to the CONTRIBUTING.md file for more detailed information.
You can review changes in this commit: https://github.com/lattaai6/prometheus-docs-2540/commit/ed91d6093568a5b8b8d0d072a005d92c18cb43dd.

[!CAUTION]
Disclaimer: This fix was created by Latta AI and you should never merge before you check the correctness of generated code!
The fix provided by Latta AI might not be complete and it can serve as an inspiration.

This issue was fixed for free by Latta AI - https://latta.ai/ourmission
If you no longer want Latta AI to attempt fixing issues on your repository, you can block this account.


Readme links to unsigned & unversioned Visual C++ Runtime File Download

Describe the bug
While i was coping with #709 i saw that the file the freshly updated readme is linking to was being detected by Edge's SmartScreen. The linked file download does not have a version, publisher name and is not signed.
Expected behavior
Microsoft Visual C++ Runtime downloads should probably be signed if propagated by security related products as a requirement.

Hi, @MeikTranel.
I don't see what you see.  The README points to https://aka.ms/vs/17/release/vc_redist.x64.exe, which I obtained from https://learn.microsoft.com/cpp/windows/latest-supported-vc-redist?view=msvc-170#latest-microsoft-visual-c-redistributable-version
I used these steps to download and verify the file:
curl -L https://aka.ms/vs/17/release/vc_redist.x64.exe -o .\vc_redist.x64.exe
signtool verify /pa .\vc_redist.x64.exe

Here's the output of signtool verify:
File: .\vc_redist.x64.exe
Index  Algorithm  Timestamp
========================================
0      sha256     RFC3161

Successfully verified: .\vc_redist.x64.exe

If you have VS installed, signtool.exe should be available through a Developer Command Prompt.


Automator: update<EMAIL_ADDRESS>dependency in<EMAIL_ADDRESS>

Generated by Automator - 2020-02-27T21:36:37+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio_release-1.5
b0413c5d1c31b4471d4776fbad2b997b13199cc0
link
/test integ-pilot-k8s-tests_istio_release-1.5

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-pilot-k8s-tests_istio_release-1.5


Share common WTR config across packages

Currently, each package defines its own config file for web-test-runner and many of them are duplicates. Additionally, each testing dependency must be installed per-project. Ideally, we should share the "base" config and dependencies across packages and allow each to extend according to their specific requirements.
This may be a use-case for Rush rig packages.

@adobe export issue to Jira project CAI


mat-radio-group data binding requires unique name

Bug, feature request, or proposal:
If a component contains mat-radio-group, and you create multiple instances of that component, the mat-radio-group names appear to collide.
What is the current behavior?
I have to ensure unique mat-radio-group names in order for data binding to work properly.
What are the steps to reproduce?
https://stackblitz.com/edit/angular-ujce61?file=app%2Ftest%2Ftest.component.html

Closing as this is working as intended.  Within forms the name for a value control must be unique to prevent this collision.

Within a form, of course names must be unique, but in this example I had 5 separate forms.
In any case, I've updated the example to remove the form altogether and the issue remains.


Add support for visibility with a fraction (eg. 2 1/2SM)

Test describes the situation. sometimes visibility comes in 2 parts, for example: 2 1/2SM.
In that case the decoder would fail to parse the rest of the Metar.
This fix corrects the visibility (visibility used to be 2 and will now be 2.5 when parsed) and the rest of the Metar is properly decoded.

Thanks for this! I was looking to solve this exact problem! You saved me a lot of time!


Make uv init options more user-friendly

Hi, thanks for uv, it's looking great.
I think this should be made a bit more user-friendly, by indicating what the defaults are, and perhaps by making it clearer which subsets make sense to be used together.
Options:
      --package        Set up the project to be built as a Python package
      --no-package     Do not set up the project to be built as a Python package
      --app            Create a project for an application
      --lib            Create a project for a library

Sure we can add a bit more context to the CLI reference, it's a bit sparse since these options are new. I'd recommend using the long-form help (uv help init) to see the more details.
Also, the documentation on this should be relatively clear https://docs.astral.sh/uv/concepts/projects/#creating-projects


add possibility to toggle every single tab if needed

All trailing spaces were removed as well at some files. I actually changed code in the app.js and the readme only.
We need this functionality as the data is set to easychart automatically from the previous step, so we do not want to show e.g. the data tab when someone creates a new chart.

ok, looks good to me

Cool, but keep in mind (for versioning) that I changed the naming of some config parameters like debugging to debuggingTab etc.

I prevented this by setting some sensible defaults


Build out our initial registry and RESTful API

Should be super straight forward:

A Redis or MongoDB data store that contains registered component names and their respective Github repo locations
An Express based REST API to serve the data

Completed in another repo: tylerdmace/periodic-registry


Support linting for python files without extension

Is it possible to add support for linting files without .py, .pyi extensions (or override the check)? We use a CLI written in python that does not have a .py extension which causes ruff to fail when running.

If you pass the file directly (“ruff path/to/file/without/an/extension”), we should lint it regardless of the extension, which is what I’ve seen other projects do. Does that help here? Or insufficient?

That doesn't seem to work. I have a github action set up that runs ruff <filename> --config pyproject.toml and ruff returns error <filename> is not supported; Ruff only supports .py and .pyi files

Is there some flag I can pass to override that error?

Looks like my ruff version was out of date.

Ah ok, that was gonna be my next question. Great!

Thanks for the quick response!


Adapt shlibloadtest for VMS

This includes a slight modification of test/simpledynamic.[ch], but most of all, this change to the test recipe:
test/recipes/90-test_shlibload.t: Modify to work with known file names
Using File::Temp::tempfile() is admirable, but isn't necessary for the
sort of thing we use it for.
Furthermore, since tempfile() returns an opened file handle for
reading for the file in question, it may have effect that the file
becomes unwritable.  This is the default on VMS, and since tempfile()
doesn't seem to have any option to affect this, it means that
test/shlibloadtest.c can't write the magic line to that file.
Also, if we consider forensics, to be able to see what a test produced
to determine what went wrong, it's better to use specific and known
file names.
Therefore, this test is modified to use well known file names, and to
open them for reading after the shlibloadtest program has been run
instead of before.

There is a small fixup, can I assume that approvals stand?

Yes

Merged.


[Bug]: System prompts are not being passed to local ollama instance

What happened?
I am running ollama locally on my M1 Mac and have the model llama3:8b specified as the default for fabric to use. When running the command pbpaste | fabric -sp label_and_rate after copying the contents of the webpage https://iximiuz.com/en/posts/thick-container-vulnerabilities/ to my clipboard, the response is not json formatted as I would expect.
kris@m1pro:~/fabric (main)$ pbpaste | fabric -sp label_and_rate
This is an article about container security, specifically the importance...

If I instead run pbpaste | ollama run llama3:8b $(cat patterns/label_and_rate/system.md) with the same webpage copied to my clipboard, I get the expected results in json format.
kris@m1pro:~/fabric (main)$ pbpaste | ollama run llama3:8b $(cat patterns/label_and_rate/system.md)
Here is the output in JSON format:

{
"one-sentence-summary": "Building container images from scratch can significantly reduce vulnerabilities.",
"labels": "Containers, Security, Docker, Vulnerability, CyberSecurity",

It seems that the system prompt is not being passed to ollama.
Version check

[X] Yes I was.

Relevant log output
No response
Relevant screenshots (optional)
No response

Hey there,
I have the same issue, on almost every patterns I've tried (extract_wisdom, summarize...) using local llama3.
I also tried this
pbpaste | fabric --model llama3:latest -sp label_and_rate
And I have a different output (that still doesn't follow system prompt)
What a fascinating journey through the world of Docker images! You've successfully created three different Python images: one based on Debian 10, another on Python 3.9 slim, and a third on Alpine Linux. Each image has its own unique characteristics and vulnerabilities.

Here are some key takeaways from your experience:

1. **Debian-based image**: The original Python 3.9 image is quite large (114 MB) and contains many potential security flaws (69 vulnerabilities). By using the `FROM python:3.9-slim` instruction, you were able to reduce the size of the image by half while still maintaining most of its functionality.
2. **Python 3.9 slim**: The Python 3.9 slim image is even smaller than the Debian-based one (54 MB) and has fewer vulnerabilities (14 high severity and 8 medium severity). This is a great example of how using a slimmer base image can lead to a more secure and efficient container.
3. **Alpine Linux**: The Alpine Linux-based Python 3.9 image is an excellent choice for those looking for a lightweight and secure option. With zero known vulnerabilities, this image is a great choice for production environments.

You also explored the concept of "distroless" images, which are language-focused Docker images that minimize the operating system's presence. This approach can lead to smaller and more secure containers, as seen in your Python 3.9 distroless image example.

Finally, you touched on the idea of building container images from scratch using a language like Go. This approach eliminates the need for a base image altogether, resulting in an even more lightweight and secure container.

Overall, your experience highlights the importance of considering image size and security when designing and deploying containers. By choosing the right base image or creating your own distroless image, you can ensure that your containers are not only efficient but also secure and reliable.

Same here, the system prompt doesn't seem to be passed or taken into account by Llama (Mac M3)

Same here too.  I've been trying to figure this out to when writing custom patterns and I just tried it with an out of box pattern and the same result as all of you.

Hi, this is a lead but I can't test it for now:
each model needs a particular message structure, for example for Mistral models, it is like this:
{System}[INST]{User}[/INST]{Assistant}
for LLama3:
<|start_header_id|>system<|end_header_id|>
{System}
<|eot_id|>
<|start_header_id|>user<|end_header_id|>
{User}
<|eot_id|><|start_header_id|>assistant<|end_header_id|>
{Assistant}
So as for local models, fabric sends the message in like this it doesn't format according to the model
messages = [{"role": "system", "content": context}, user_message]
Maybe try to create a system.md file with your system prompt in the format required by your model, and format also your user message and test ...
If it works, may be ask for a new feature that could be a "--message-format" argument to fabric in order to provide model specific format.

Thx, I was also thinking about that. But as Ollama is supposed to provide a kind of abstraction within its python library (same ways to request the model whatever the one that is chosen), I would naively think that it’s the responsibility of this Ollama lib to format system message from a simple text string to the appropriate format for the chosen model within Ollama.. but it didn’t checked the Ollama lib code to see how it is implemented…

Ive run into the same issue while using my local model. I am however able to use a remote Ollama server. I think this gives credence to the idea that fabric is just not passing on the prompt to the local model, as a remote server would also have to request the file path and contents on the pattern from the client

I'm facing the same issue on Linux. Regardless of the model, the pattern doesn't seem to be used.

If i make a --remoteOllamaServer call on the machine which is actually running the model then it works. But it refuses to run on the machine natively regardless of what OS I am using (I have tried WSL and Linux)

Same issue here.


Markdown render issue?

0. A
1. B
2. C

will yield markup for items 1. & 2. only.

cleaver version 0.7.2

You may need to change your rendered html <ol> to  <ol start='0'>

I guess this is due to whatever markdown parser we are using, in which case it might be a bug on their end.

This no longer the case for 0.8.2. 🎉


Orgbook Test - adding new company

Hi,
Can you please add the following company to Orgbook test?
Company Number: BC0883960
Name of Company: CLIENTTEST SUSAN LTD.

@amanji --- can you please take this one?  With Test now loading, this can be added to the queue now.  @jonargue -- hopefully you got my email this morning about the reload we are doing on OrgBook Test.  It may be that this will not be loaded until the end of the rest of the loading.
Thanks

Saw it - no problem with the load timeline.
Jonathan Argue
Consultant
J.S. Argue and Associates Ltd.
Email: @.***
Cell:<PHONE_NUMBER>
www.jsargue.ca
www.imaginarytable.ca
On Tue, 17 Aug 2021 at 15:36, Stephen Curran @.***>
wrote:

@amanji https://github.com/amanji --- can you please take this one?
With Test now loading, this can be added to the queue now. @jonargue
https://github.com/jonargue -- hopefully you got my email this morning
about the reload we are doing on OrgBook Test. It may be that this will not
be loaded until the end of the rest of the loading.
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bcgov/orgbook-bc-client/issues/29#issuecomment-900676307,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKRTPVZWLJIZN557SV54BTT5LP5LANCNFSM5CKYRWAA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

--
IMPORTANT: This transmission is sent on behalf of J.S. Argue & Associates
Ltd. and it may be privileged, proprietary or confidential. If you are not
the intended recipient or a person responsible for delivering this
transmission to the intended recipient, you may not disclose, copy or
distribute this transmission or take any action in reliance on it. If you
received this transmission in error, please notify us immediately by
telephone at<PHONE_NUMBER> and please dispose of and delete this
transmission. Thank you.

This is done -- please reopen if there are any issues.
https://test.orgbook.gov.bc.ca/en/organization/registration.registries.ca/BC0883960


Don't filter on userId for counting webhook stripe received activities...

... because their UserId is null anyway

We shouldn't have any transactions with userid null. Where are those coming
from?
On Mon, Apr 25, 2016 at 4:40 PM Sébastien Dubois<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/OpenCollective/api/pull/300
Commit Summary

Also consider transactions with null UserId in transaction report

File Changes

M scripts/report_transactions.js
https://github.com/OpenCollective/api/pull/300/files#diff-0 (33)

Patch Links:

https://github.com/OpenCollective/api/pull/300.patch
https://github.com/OpenCollective/api/pull/300.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/OpenCollective/api/pull/300

Right, I titled wrong, I was actually doing the fix for the count of activities, not transactions. But I simplified the PR to make sure to only impact the counting on that table, very simple now...


Rework meson and use subdir() for library

Meson rightfully prohibits sub-projects to be referenced via .. or a full path.  Meson needs this file to be in the root of the source tree. I attached a fully working template based on the template provided by the xpack extension. In contrast to the original template, it in fact compiles add.c as a shared library. It also has a few other goodies: (i) the default task is set to xPack: build Debug, so it can be launched with Ctrl+Shift+B; (ii) launch is configured to run gdb and to perform a build before starting debugging; (iii) c_cpp_properties.json is set up to work correctly in any configuration, in any subprojects of any subdirectory without configurationProvider property.
Since we discussed in another issue if configurationProvider is needed, you can turn off CMake Tools extension completely and see that IntelliSense is still working after removing configurationProvider, restarting VS Code and after resetting IntelliSense database. Shaded areas of inactive code will react correctly on switching configurations between Debug and Release.
xpack.zip

I transferred this ticket to the template repository, which defines the location of the meson.build file.
I also added a separate ticket: https://github.com/xpack/vscode-xpack-extension-ts/issues/19.
As for the location of the meson.build, my experience with meson is not great, and I have to better understand the details before considering changes.
Personally I prefer to not have the metadata/build files in the project root, and keep the focus on the source code.
As for the attached zip, I tried to use it on my Mac, but it is not portable, it failed with a missing dependency on meson, which is not present in the system path as on your Linux.
For a template to be really useful, it must be standalone and run on all platforms (Linux/macOS/Windows).
But templates are entirely open, you can create as many templates as you desire, and use them to instantiate projects with xpm init --template.

The project I attached was meant to serve as just an example of how to use Meson correctly. I thought you would use it to modify the existent Hello World template, not use it as is.

Aha, ok.
Any special reason for removing the devDependencies to the binary xPacks?

Any special reason for removing the devDependencies to the binary xPacks?

I have no idea what you are talking about. I just tried to compose a minimum working example, I guess no reason at all. :)

The xPack project provides a convenient way to add dependencies to specific versions of the required binary tools, such that you always build your project in the same environment, regardless of the platform you use. This is particularly useful when running unit tests on a CI server. Even more, you can define dependencies for each build configuration, such that you can, for example, build the same test with different versions of the toolchain.
The syntax of devDependencies property in package.json is inherited from npm, and you can see an example in the projects generated by the template.
The dependencies are processed by xpm install. If, for any reason, you decide to use the tools available in the system, you can skip the invocation of xpm install, or you can remove the xpacks folder.
But it is still a good idea to have the devDependencies defined by you projects, in case you want to build them on other platform than Linux.

Ok, got it. Thank you for the explanation. I will use it.

FYI, at the moment I have only a GCC 8 xPack, but 9 and 10 will be published soon, after I finalise clang 11 xPack.
For meson and ninja, I am generally no more than a release behind the upstream project, so I think this is reasonably up to date.

I took a look at your suggestion to split the meson configuration and use subdir() to include the separate library definitions.
I'll try to update the template to use it, and let you know the result.

I published a new release of the template using your suggestions.
Please test it with:
mkdir -p ~/tmp/test-hello
cd ~/tmp/test-hello
xpm init --template @xpack/hello-world-template@next
xpm install
xpm run test

For now the project is @next, if you confirm it is ok I'll promote it to @latest.

@intractabilis, any chance to check if the meson code used by the new release is ok?

Sorry for a delay.
Here is the command line generated for the .cpp file:
g++ -Ihello-world.p -I. -I../.. -I../../include -I../../libs/adder/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -g -DDEBUG -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-omit-frame-pointer -MD -MQ hello-world.p/src_hello-world.cpp.o -MF hello-world.p/src_hello-world.cpp.o.d -o hello-world.p/src_hello-world.cpp.o -c ../../src/hello-world.cpp

Obviously, gnu++17 didn't find its way to the command line.

However, the objective of this issue is fulfilled, gnu++17 is another problem.

Hmmm... indeed. Since my knowledge of meson is quite poor, do you have any suggestion where to add this definition so that it'll find its way to the command line?

It should be in the project statement. I believe it also can be set in another way, but Meson developers recommend the project statement. It's in my example I attached earlier.

Aha, so it must be passed via the project statement. I added a separate issue and fixed it.

Fixed on 2021-06-20.


recordPerson not working when using mockCohort()

When trying to use the argument recordPerson in mockCohort() function, it does not work as I expected. Am I doing something wrong?
cdm <- omock::mockCdmReference() |>
  omock::mockPerson(nPerson = 10) |>
  omock::mockObservationPeriod()

cdm <- cdm |> omock::mockCohort(recordPerson = 1)

cdm$cohort
#> # A tibble: 10 × 4
#>    cohort_definition_id subject_id cohort_start_date cohort_end_date
#>                   <int>      <int> <date>            <date>
#>  1                    1          1 2001-05-30        2003-05-01
#>  2                    1          1 2003-05-02        2006-06-10
#>  3                    1          2 2000-05-04        2000-05-17
#>  4                    1          2 2000-05-18        2001-01-23
#>  5                    1          3 2015-01-27        2015-06-28
#>  6                    1          4 1996-06-30        1998-11-20
#>  7                    1          5 2012-03-20        2012-04-30
#>  8                    1          5 2012-05-01        2012-07-24
#>  9                    1          7 2014-03-07        2014-03-07
#> 10                    1          7 2014-03-08        2014-03-20

Created on 2024-06-05 with reprex v2.1.0

recordPerson is an average. you have 10 people in person table, so it gives you a cohort of 10 x 1 rows.

I see! Thank you Mike!


PHP Fatal error:  Uncaught MySQLReplication\Socket\SocketException

Please provide the following details.

Operating System: Linux Ubuntu 18.4
PHP Version: 7.2
php-mysql-replication Version: 7.0
*mysql version (SELECT VERSION();):  MySQL 8.0

Steps required to reproduce the problem.

Connecting to replica
Start consuming

Expected Result.

The replication application should work continuously, it works for sometimes and throws error.

Actual Result.

After running for few seconds, sometimes minutes it throws the following error;
PHP Fatal error:  Uncaught MySQLReplication\Socket\SocketException: Success in /var/apps/nxo-fetcher-new/src/MySQLReplication/Socket/Socket.php:65
Stack trace:
#0 /var/apps/nxo-fetcher-new/src/MySQLReplication/BinLog/BinLogSocketConnect.php(63): MySQLReplication\Socket\Socket->readFromSocket(1273)
#1 /var/apps/nxo-fetcher-new/src/MySQLReplication/Event/Event.php(57): MySQLReplication\BinLog\BinLogSocketConnect->getResponse()
#2 /var/apps/nxo-fetcher-new/src/MySQLReplication/MySQLReplicationFactory.php(130): MySQLReplication\Event\Event->consume()
#3 /var/apps/nxo-fetcher-new/src/MySQLReplication/MySQLReplicationFactory.php(116): MySQLReplication\MySQLReplicationFactory->consume()
#4 /var/apps/nxo-fetcher-new/app/stream.php(78): MySQLReplication\MySQLReplicationFactory->run()
#5 {main}
thrown in /var/apps/nxo-fetcher-new/src/MySQLReplication/Socket/Socket.php on line 65

@krowinski, can you please provide me any update on this?


Selecting snippets with '' at the beginning of the trigger word causes another extra '' to be added.

Checkhealth
Put result of :checkhealth compe.
health#compe#check
========================================================================
## compe:snippet
  - OK: snippet engine detected.

## compe:mapping
  - INFO: `compe#complete` is not mapped
  - INFO: `compe#confirm` is not mapped
  - OK: `compe#close` is mapped: (`i  <C-Y>       * compe#close('<C-Y>')`)
  - INFO: `compe#scroll` is not mapped

Describe the bug
I use ultisnips for snippets. I don't want snippets to trigger everytime I type 'begin" in a latex document. So I have '\begin' as the trigger. The problem is that when I select the completion compe adds another '' at the beginning. I haven't checked the bug with other special characters. Only '\' so far....
To Reproduce

Create an ultisnips snippet with '\' at the beginning
Open a latex document.
Select the snippet from the popup menu.

Actual behavior
Compe add an extra '\' at the beginning.
Expected behavior
Compe should not add an extra '\'.
Screenshots (optional)

Before selecting...

After selecting...

I think I am having a similar issue with LSP completions
Setup

Completed


chore(npm): sync package.json from npm-package-template

engines, version, release scripts for semantic-release, mocha, jsdoc and istanbul

Current coverage is 100.00%

Merging #17 into master will not affect coverage as of 3b2e733

@@            master     #17   diff @@
======================================
  Files            6       6
  Stmts          106     106
  Branches        10      10
  Methods          0       0
======================================
  Hit            106     106
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of 3b2e733

Powered by Codecov. Updated on successful CI builds.


Maybe remove reusable string step from CI?

Maybe remove reusable string step from CI? Not sure if it is necessary.

The reusable string build-output-dir is used further down the file and cannot be removed.

Won't fix.


NavbarBrand doesn't accept Link as tag

Using the following:
      <AppNavbarBrand
        tag={Link}
      />

will throw warning message: "Warning: Failed prop type: Invalid prop tag supplied to AppNavbarBrand.". I didn't find out how to pass a custom clickable Link component. Can you suggest?

Hi @o1dnik
What about:
<AppNavbarBrand
  tag={NavLink}
  to="/users"
  full={{ src: logo, width: 89, height: 25, alt: 'CoreUI Logo' }}
  minimized={{ src: sygnet, width: 30, height: 30, alt: 'CoreUI Logo' }}
/>

@xidedix I've tried with NavLink before creting this issue because I read your suggestion in another thread. But it does not work either. Here's the exact snippet of what we use:
      <AppNavbarBrand
        tag={Link}
        to={reverse(urls.dashboard)}
        full={{ src: logo, width: 40, height: 40, alt: "..." }}
        minimized={{ src: logo, width: 40, height: 40, alt: "..." }}
      />

where reverse function just returns a string (correct for router).

@o1dnik
Let's try this way:
<Link to={'/users'}>
  <AppNavbarBrand
    tag={'div'}
    full={{ src: logo, width: 40, height: 40, alt: "..." }}
    minimized={{ src: logo, width: 40, height: 40, alt: "..." }}
  />
</Link>

Yep, this workaround works fine, though I thought I could pass the component as Tag to be rendered. Thank you for the suggestion


library not found for -lRCTGCanvas

I am using the react native bridge and it is working fine in Debug Scheme, but I get the following error when I try to Archive the project in xcode or generate a Release build:
Current behavior
when building the project for release:
xcodebuild "-project" "ios/BetClash.xcodeproj" "-scheme" "BetClash" "-configuration" "Release" "archive" "-verbose" | xcpretty

The linker fails with:
ld: library not found for -lRCTGCanvas

Expected behavior
It should build without errors.
Env:
node: v9.11.2
npm: 5.6.0
xcode: 9.4.1

in xcode, click the RCTGCanvas project in Libraries dir, change the build target version to same as your project target.
for example, your project build target version is ios 11.0, then change RTCGCanvas.xcodeproj to same.

Refer https://stackoverflow.com/a/58566191/515932


Specifying the request.class type similar to request.class

For the below function type, i cannot specify the class format for the input\request parameters as we can for the response types. I know the class format which the request parameter is represented and want to show the same in the API documentation, but actually i am using the InputStream as to read the data.
Expecting something similar to how "response = User.class" behaves
Explored @ApiParam, but no suitable option found.
@ApiOperation(value = "save a user", response = User.class)
@POST
public Response saveUser(InputStream message){...}

That's true, you cannot (and this is intentional).
You'd have to hide that parameter, and re-add it as an @ApiImplicitParam.

The schema type does not refer the dataType specified. it always points to be a string. Which is a bug i guess. Refereed the issue which points to the same behavior.
@POST
@ApiOperation(value = "save a user", response = User.class)
@ApiImplicitParams({
@ApiImplicitParam(name="inputObj", value="Input param", dataType="MyObj")
})
public Response saveUser( @ApiParam(hidden=true) InputStream message){...}

as long as MyObj can be resolved, it'll be resolved and added correctly.


Add BE server to FE overview pages

closed with merge https://github.com/DigitalProductInnovationAndDevelopment/Project-Staffing-Application/pull/91


Replace define equal with :=

-[ ] Replace define equal with :=
-[ ] \mathcalH should be \mathcal{H}_{\colorS} and maybe also incorporate \colort

note: sometimes \mathcalH_{\colort} seems to be being used


Restructure the user guide

Issue Description
What did you expect to see happen?
The user guide is preferred to be more application-oriented.
What did you see instead?
The current user guide is more capability-oriented
Do you have a suggested fix for the development team?
Restructure the user guide
Please attach the input file(s) that generate this error.  The simpler the input, the faster we can find the issue.
N/A

For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.

[x] 1. Is it tagged with a type: defect or improvement?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users. Not a defect
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.

[x] 1. If the issue is a defect, is the defect fixed? Improvement made
[x] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.) Not defect
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)? Not defect
[x] 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)? Not defect
[x] 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided? Closed with merge

Close reviewed by @joshua-cogliati-inl

This issue can be closed by PR #177


XD-2646 XD should use same hadoop security keys as Spring for Apache Had...

...oop

Yes, lgtm.

merged.


Timeout after two 204 resulting queries

If I use the ZCRMModule.SearchByPhone() on Leads (although issues regardless of entity type) with a number that doesn't match any records then I get a 204 results which is expected.  However if I make the same query two more times, the second time it fails with again with a 204 (expected) but the third time it times out after 40 seconds.  This does not seem to be an issues with the REST API itself as invoking the phone search from postman works fine regardless of how many times.  Note that doing a search which returns results does not result in any eventual query problem.

@schenckg - Thanks for reaching out.
I think you are posting a bug on the wrong repo. This SDK or NuGET only contains API calls for Zoho Subscription.


TreeviewPipe not yet transform children

Hi, Thank you very much for the control.
it great
I have a small problem that Treeview pipe not yet transform children of node.
I must create new my treeview pipe to solve it.
You can check it.
thanks

Yes, it does not support. You should write a helper to transform yourself.


Managed Service Mesh

Most probably Istio. Alternatively, we might also offer linkerd 2 for its simplicity.

Closing in favor of https://github.com/giantswarm/roadmap/issues/290


qb_hand: 2.0.0-0 in 'lunar/distribution.yaml' [bloom]

Increasing version of package(s) in repository qb_hand to 2.0.0-0:

upstream repository: https://bitbucket.org/qbrobotics/qbhand-ros.git
release repository: https://bitbucket.org/qbrobotics/qbhand-ros-release.git
distro file: lunar/distribution.yaml
bloom version: 0.6.4
previous version for package: null

qb_hand

No changes

qb_hand_control
* Update README
* Refactor launch files
* Remove control node
* Add blocking setCommands method support
* Refactor launch files
* Fix destructor calls on ROS shutdown

qb_hand_description
* Update README
* Update xacro models
* Refactor launch files
* Refactor launch files

qb_hand_hardware_interface
* Refactor transmission initialization
* Refactor initialization
* Prepare for CombinedRobotHW compatibility

With the other PR merged this needs to be rebased to be mergable again.

Once #18053 has been merged this will need a rebase again. So I would suggest to wait with the rebase until after that.

Sorry guys, I always forget not to parallelize these tasks...


autocompletion as separate plugin

just a suggestion to make the completion a different plugin so that snippet and other completion can be used even if the lsp is not running

No, please, for what? Asynccomplete and ddc are weak and slow compared to this plugin.

This plugin is a good monolith


lv_cb_get_style of LV_CB_STYLE_BG returns NULL

I found a small bug where get style of the checkbox widget returns NULL if the type is LV_CB_STYLE_BG. It seems to me since checkbox is inherited from the button widget that the background style is not correctly saved within the private data of the widget. (see lv_cb.c at line 209 to 215)
I'm using the dev-6.1 branch.

Nice catch!
https://github.com/littlevgl/lvgl/blob/bbf2c8247ccca1fabee135feab52c9c7f58d76f4/src/lv_objx/lv_cb.c#L209-L216
I think the simplest solution would be to just retrieve any one of the ancestor button's styles.
case LV_CB_STYLE_BG: style = lv_btn_get_style(cb, LV_BTN_STYLE_REL); break;

This should work because whenever the background style is set, all of the button styles are changed.

@CURTLab Could you try adding the line I suggested in lv_cb.c and see if it works for you? If it does I will apply the patch to master (provided that @kisvegabor approves of it).

Really nice catch!
I've tested @embeddedt's proposed solution and it worked well.

I've just fixed it on both master and dev-6.1 as @embeddedt suggested.


Feature/url based ids

Specify all author Ids in the domain object as the full HATEOS URL
Handle HATEOS author ids when handling a comment post

Handle HATEOS author ids for friend based requests


Ubuntu Errno: 1 permission denied

Alright people i have dug into this one as far as i can so looking for some help. attached are my logs and the error i have gotten.
I'm running Ubuntu 20.10 on Intel NUC utilizing a linksys wusb6300. i'm able to connect to vtrust wifi on my phone but as soon as i hit enter i get this error and i can't tell what it thinks it doens't have permission for.
Any support would be appreciated.
Traceback (most recent call last):
File "./smartconfig/main.py", line 26, in
smartconfig( passwd, ssid, region, token, secret )
File "/home/plex/tuya-convert/scripts/smartconfig/smartconfig.py", line 54, in smartconfig
sock.send_multicast(multicast_head)
File "/home/plex/tuya-convert/scripts/smartconfig/smartconfig.py", line 39, in send_multicast
self._socket.sendto( b'\0', (ip, 30012))
PermissionError: [Errno 1] Operation not permitted
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log

Did you manage to find a solution? I'm running into the same error. Thanks mate.


Fix npmignore and files field

Right now the published tarball of the repo potentially contains a ton of files that should not be published.
This changes the files field in package.json to include specific directories, now combined with targeted .npmignore files for each platform.
On my development machine the numbers are down from
npm notice === Tarball Details ===
npm notice name:          react-native-device-info
npm notice version:       5.2.1
npm notice filename:      react-native-device-info-5.2.1.tgz
npm notice package size:  187.9 kB
npm notice unpacked size: 826.1 kB
npm notice total files:   143

to
npm notice === Tarball Details ===
npm notice name:          react-native-device-info
npm notice version:       5.2.1
npm notice filename:      react-native-device-info-5.2.1.tgz
npm notice package size:  98.0 kB
npm notice unpacked size: 509.0 kB
npm notice total files:   67

Thank you! :bowing_man: you should have seen the size of the releases on npm temporarily before I realized what had happened and published smaller point releases. 200MB one time! That motivated me to look for a solution but I didn't have a good one yet. This is great
My only question, why not e.g. '/lib/' vs 'lib/' - i.e., rooted instead of rootless? Does it matter? Seems like rooting it would be the most precise expression but I may be missing why it doesn't even matter

Yeah, very good observation. :) Just a couple of days ago I was wondering about the same exact thing (leading slash required or not). What I found was that with or without the leading slash, only root directories (basically on the same level as the package.json) are considered.

Also, I have a quick question: It's correct to publish both lib/ and src/, correct? (I saw lib/ is generated, and I'm not familiar with bob)

That leading slash thing is...perplexing. So it's like a regex, except it's not? Okay then ;-)
Technically you don't have to publish src but I have a hard rule for my repos which is to handle the "patch-package" use case well. That means specifically that anyone should be able to go right into the node_modules folder on my module, tweak something (in the actual implementation file) as a test for a fix, run a one-line build called "build", and have it work.  I learned that from reactxp vs a few other projects. reactxp got it right (source included! one line build!) and gained me as a contributor as my drive-by dev experience is so easy. The other projects were less fun to patch up

Makes sense, thanks for explaining! 👍

Looks fine on review of course, and I usually do RNDI releases over the weekend these days, so I'll exercise it completely shortly. Thanks again!


Server must return 505 error code when incoming request does not use HTTP 1.1

The check can happen after the following lines. Do the check near these lines covers all endpoints.
https://github.com/irods/irods_client_http_api/blob/17b8defb32948a8110dceab956b86fc0c476a5f4/src/session.cpp#L97-L105

Boost.Beast automatically handles this.
To test, run the following:
curl --http2-prior-knowledge -v http://localhost:9000/irods-http-api/0.1.0/info

--http2-prior-knowledge skips negotiation and assumes the server supports HTTP/2.
Closing.

Can you document here the reply from Boost.Beast / HTTP API when the --http2-prior-knowledge is sent?

Here it is ...
$ curl --http2-prior-knowledge -v http://localhost:9000/irods-http-api/0.1.0/info
*   Trying <IP_ADDRESS>:9000...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 9000 (#0)
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5625ce8de220)
> GET /irods-http-api/0.1.0/info HTTP/2
> Host: localhost:9000
> user-agent: curl/7.68.0
> accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server

Without any changes to the HTTP API server, it logs the following and ends the client request.
[2023-08-27 16:19:32.699] [P:2854093] [error] [T:2854173] fail: read: bad version

Excellent.   We'll get that into the Usage / README.


Slave Support

A Debian slave script was added by https://github.com/jenkinsci/puppet-jenkins/commit/a22888ff871199bb1259e706ceabd3d3eb767411, I think it's reasonable to close this PR.


POST method doesn't send any body

Hi Bruce,
I suspect that when you refactored the post() method to use GuzzleFactory, you accidentally removed the $config with $json.
https://github.com/phpfui/ConstantContact/blob/557de6a51d02aec5ce8cbb9c161bd9b10d3adadf/src/ConstantContact/Client.php#L290
history:
			$json = \json_encode($parameters['body'], JSON_PRETTY_PRINT);
			$guzzle = new \GuzzleHttp\Client(['headers' => $this->getHeaders(),
				'handler' => $this->guzzleHandler,
				'body' => $json, ]);
			$response = $guzzle->request('POST', $url);

current version:
			$json = \json_encode($parameters['body'], JSON_PRETTY_PRINT);
			$response = $this->getGuzzleClient()->request('POST', $url);

compared to put() method
			$json = \json_encode($parameters['body'], JSON_PRETTY_PRINT);
			$guzzle = $this->getGuzzleClient(
				$json,
				[
					'Connection' => 'keep-alive',
					'Content-Length' => \strlen($json),
					'Accept-Encoding' => 'gzip, deflate',
					'Host' => $this->host,
					'Accept' => '*/*'
				]
			);
			$response = $guzzle->request($method, $url);

Perhaps you even meant to remove the post() method's guts and call put($url, $parameters, $method = 'POST').
I found out because Constant Contact complains
[{"error_key":"contacts.api.validation.error","error_message":"create_source is missing, create_source does not have a valid value"}]

when I'm trying to add a contact. The parameter create_resource is in $json
{
  "create_source" : "Contact",
  "first_name" : "John",
  "last_name" : "Doe",
  "list_memberships" : [ "4315271a-92f6-11ef-8029-fa163ecd39be" ],
  "email_address" : {
    "address"<EMAIL_ADDRESS>    "permission_to_send" : "explicit"
  }
}

and the JSON is accepted without complains (and contact is created) when I send the request from PhpStorm directly.
That got me investigating the code of post().

Yes, forgot to pass the json body to the factory.  Now fixed.  Let me know if this works and I will create a release.
I had to submit PR's to two other packages since they have depreciations under PHP 8.4, which I am now running. Such is life on the cutting edge. Hopefully the maintainers will merge, but I have my doubts.

Thank you for your speedy reaction. It's working now.
Looking at post() though, I notice that it doesn't send the same headers as put(). Also, the similarity of these two methods is striking, and you can even define which http method should be actually used with put(). So I'm curious, why didn't you write:
	public function post(string $url, array $parameters) : ?array
		{
		return $this->put($url, $parameters, 'POST');
		}

You did the same with patch().
It would be even cleaner to extract the functionality of put() to some private method e.g. request() and call $this->request($url, $parameters, 'PUT');

Yes. Was noticing that too. But apparently I thought they were different
enough to be separate. Maybe one did not require length?
On Sat, Nov 23, 2024, 8:09 AM xpavp03 @.***> wrote:

Thank you for your speedy reaction. It's working now.
Looking at post() though, I notice that it doesn't send the same headers
as put(). Also, the similarity of these two methods is striking, and you
can even define which http method should be actually used with put(). So
I'm curious, why didn't you write:
public function post(string $url, array $parameters) : ?array
{
return $this->put($url, $parameters, 'POST');
}
You did the same with patch().
It would be even cleaner to extract the functionality of put() to some
private method e.g. request() and call $this->request($url, $parameters,
'PUT');
—
Reply to this email directly, view it on GitHub
https://github.com/phpfui/ConstantContact/issues/29#issuecomment-2495474754,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYW6S5TU4TDXEFG6NDYS432CB5AXAVCNFSM6AAAAABSJZC6DKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVGQ3TINZVGQ
.
You are receiving this because you commented.Message ID:
@.***>


Load tests for catalog search

Tests for ECOM-2668. @clintonb please review.
FYI @edx/ecommerce

👍


Add --cesium flag for exporting a model with the Cesium sun as a light source

Fixes #114
Added a command line flag --cesium for optimizing a model for use in Cesium. Right now this just means using czm_sunDirectionEC in the shader, but there could be other use cases for a having a Cesium-only pipeline. By default if a model does not have lights/shaders and goes through modelMaterialCommon, it will use a light source that is always pointing in the direction of the camera, which is the same behavior as COLLADA2GLTF. The images below show with the flag set vs. not set.

I need to fix some failing tests quickly.

@pjcozzi Do you think this should be a checkbox in the online converter?

Updated.

Coverage decreased (-0.03%) to 93.985% when pulling 4c6be23d6fee8b1c517398a39f39857aa14fece8 on change-default-light into d8d1c4d21984610a292200580a31590b40c87dd9 on master.

@pjcozzi Do you think this should be a checkbox in the online converter?

No, at least not yet.  I don't want to expose too many options and complicate the interface until there is strong demand for a feature.

Are you adding more unit tests for this?

Are you adding more unit tests for this?

Ah yes I should.

Added a test.

Coverage increased (+0.2%) to 94.175% when pulling 11906c604dc0df2aec7e53e169ef9f296878a05a on change-default-light into d8d1c4d21984610a292200580a31590b40c87dd9 on master.


Button to create a new stream is not visible in mobile browser

When I tried to create a new test stream in my test organisation, in my mobile browser, I added stream name and description. Now create stream button is at bottom in this form. I scroll down to most possible bottom side in browser, but button is still not visible. Only a 5-10% of its portion is visible(Only top line of button).

@ruchit2801 this may be something you need to help debug.  I'm sure there is some sort of CSS change workaround that can fix this, but it probably requires someone with a reproducer to try things out.  It does seem like something is off in how heights are calculated.

okay! @timabbott. A small doubt, how am I supposed to test changes in mobile web, we create server in Desktop, but what should be done in android?

The create stream modal is not the only screen with this issue.
Even the modal with list of streams is cut off from the bottom on mobile.

This is still an issue on both chrome and safari on my iOS xe device.

@lukehayes1101 can you open a separate issue?  This is likely resulting from an unrelated regression.


Create maxhitalert

This plugin allows you to receive discord notification whenever the player gets a max hit. You can set the discord webhook url in the plugin settings.

Inject our okhttp client instead of making your own
Use enqueue instead of execute

See https://github.com/Adam-/runelite-plugins/blob/discord-loot-logger/src/main/java/info/sigterm/plugins/discordlootlogger/DiscordLootLoggerPlugin.java for reference

Use clientThread invokeLater to wrap your addMessage call on https://github.com/doppy2023/maxhitalert/blob/5e8362e93c993918fe03157250fe9df1c0a477b9/src/main/java/com/maxhitalert/MaxHitAlertPlugin.java#L86 and it will be good
https://github.com/raiyni/example-plugin/blob/bank-screenshot/src/main/java/io/ryoung/bankscreenshot/BankScreenshotPlugin.java#L75

thank you for your patience boss


Console:  key does not clear line as expected

From pierre.raybaut on 2010-09-26T07:07:55Z
Everything is in the title...
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=392

From pierre.raybaut on 2010-10-17T13:31:07Z
Replaced by Shift+Escape
Status: Fixed


synonym search no longer working

mts2 does not find
http://pombase2.aska.gen.nz/gene/SPBC4.07c

It works for me.  Does it show any results at all for you?
I get:

works for me now too!


[Get-DbaDbUdf] filtering on object name and schema name without using Where-Object

Summary of new feature

Clear/concise description of what the problem is that the new feature can solve.

Currently, the Get-DbaDbUdf command returns all the objects, unless we filter out by database (Database, ExcludeDatabase) or system objects (ExcludeSystemUdf).
There is no way to filter it by name or schema name other than Where-Object. There are more functions like that.
Examples where we filter by object name or schema:

allows three-part names search in an object parameter)
Get-DbaDbView (-View)
Get-DbaDbTable (-Table)

(uses Schema and Synonym parameters
Get-DbaDbSynonym (-Schema, - Synonym)

Proposed technical details (if applicable)

e.g. Blog post reference that shows example code or functionality
Approach from one of the functions above.

Latest version of dbatools as of writing

Please provide the latest released version of dbatools module.
1.0.169

Maybe we can take all the Get-DbaDb* commands, have a look and propose one pattern for all of them. It would be really nice if similar commands have similar interfaces.
Do you see one or two commands that have a very good design?

I will have a look, but definitely, one pattern would be great. At the moment it is a mixture of different approaches, so while we are going to unify Remove-* functions it would be great to do it with the relevant Get-* as well.
There were recently created new functions for Synonyms/Sequences/Schemas. Maybe that's a start, as probably there were most recent discussions on those.

I copied the functionality from Get-DbaDbSynonym as implementing 3-part-names is more complex.
Please have a look at the pull request and give feedback.

Looks good to me :) Should we follow that template for other Get-Dba* commands, so this works nicely with Remove-Dba* cmdlts?


Review LSD contracts

Similar to the prior LUSD analysis, review the smart contracts for each LSD that OETH will support as minting collateral and confirm that there aren't any red flags.

[x] rETH
[x] frxETH

Moved stETH to https://github.com/OriginProtocol/origin-dollar/issues/1345

Links for the work
rETH: https://docs.google.com/document/d/1HIcJ0ecpeM45caowBHVLOfM7U0zBrcg3w4589QHgvGM/edit
frxETH: https://docs.google.com/document/d/1voXJs2PlLiSUGhOB4sF8i62l1d1AvN7gmJ8diQyXZy4/edit


alejandra: 0.4.0 -> 0.5.0

Motivation for this change
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

nix-build -A alejandra -A pkgsStatic.alejandra -A pkgsCross.aarch64-multiplatform.pkgsStatic.alejandra -A pkgsCross.armv7l-hf-multiplatform.pkgsStatic.alejandra -A pkgsCross.gnu32.pkgsStatic.alejandra -A pkgsCross.raspberryPi.pkgsStatic.alejandra -A vscode-extensions.kamadorueda.alejandra
/nix/store/ak0qy6c1flcv5dc5vzx37kcfmbxq1384-alejandra-0.5.0
/nix/store/63ysrp1v10d3lhnvn2rgwsqm5a12x35v-alejandra-static-x86_64-unknown-linux-musl-0.5.0
/nix/store/d7g4w2sxnf1j5sj6x4wnccij372rq0lc-alejandra-static-aarch64-unknown-linux-musl-0.5.0
/nix/store/wnfbvlrpvlic53djyp3ib08j59ch8sl7-alejandra-static-armv7l-unknown-linux-musleabihf-0.5.0
/nix/store/dl7q5liiinmrrszbf7jz1f8rbmiy2gl0-alejandra-static-i686-unknown-linux-musl-0.5.0
/nix/store/5w0kyjk0rab06qlrm4gzh1gv1z2fbvdi-alejandra-static-armv6l-unknown-linux-musleabihf-0.5.0
/nix/store/9wbwh2llnksmrv55jlczdrgifggrhnd2-vscode-extension-kamadorueda-alejandra-1.0.0

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

2 packages built:

alejandra
vscode-extensions.kamadorueda.alejandra


Add noise duration indicator

This PR adds...
When you record a sound, a stem grows. It shows you how long the sound is.
More to come, this is just some initial work.
Relates to #171

This is broken, i can move it out of range

This is broken, i can move it out of range

More to come, this is just some initial work.


Fix for jars not getting deleted

Fixes #71 and also fixes an issue with benchmark results written to disk not getting coalesced.

Codecov Report

Merging #74 into master will not change coverage.
The diff coverage is 100%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2fa87f1...b805b06. Read the comment docs.


'No compatible binary build found for this package'

Just upgraded to Meteor <IP_ADDRESS>, are you waiting for 1.4 to publish a new release? Understandable if so, I'm just wondering if this is a fluke. Thanks for your help!

There shouldn't be any need for binary builds anymore. Are you using the latest version (2.1.0)?

I just had to re-link node-sass as per the instructions, and include the outputJsFilePath defs in package.json. This is probably because I haven't updated react-toolbox to 1.0 yet. All good!


add optional artifactType to image manifest for oci v1.1

Add an optional artifactType field to the image manifest to reflect the new changes for OCI v1.1.
See: https://github.com/opencontainers/image-spec/blob/main/manifest.md#image-manifest

Thank you for the review and merge, @flavio!


Example.java compilation error, Java build fails, libtdjni cannot be generated

Compilation error in Example.java lines 305-306, master branch

Unhandled Exception (screenshot)

Inconvertible Types (screenshot)

Prevents from compiling Example.java and building libtdjni

Caused by this commit: https://github.com/tdlib/td/commit/dd77e4628f1a65f332f0cb81c82a19c0fcfa40c2, reverting it resolves this issue

The regression was fixed in TDLib 1.8.21, which will be released soon. For now, I would recommend to revert the last master commit as you did.


a favicon based on wpmlogo.png is genared and linked in the index.html page

result:

Thank you for doing this


ENH: add some tests for antsRegistration in float mode

Recently, antsRegistration is enhanced to be able to process data in single
precision. The related changes were pushed to ANTs repository, but there
were no test related to them.
The problem was that new tests could not be feeded by double type initial
transforms.
I converted those double type initial transforms to single precision
type using the newly enhanced BRAINSTransformConvert tool.
Then, I added some tests for the antsRegistration in single precision
mode. Test changes and related baselines are commited here.

@hjmjohnson @stnava
Please review this pull request.

hi ali - added you as collaborator if you'd like to commit (at least safe)
things such as this w/o pull requests
brian
On Thu, Jan 15, 2015 at 7:28 PM, Ali Ghayoor<EMAIL_ADDRESS>wrote:

@hjmjohnson https://github.com/hjmjohnson @stnava
https://github.com/stnava
Please review this pull request.
—
Reply to this email directly or view it on GitHub
https://github.com/stnava/ANTs/pull/151#issuecomment-70189182.

That's great! Thank you Brian.
Ali

@aghayoor Ali,  You have grouped two patches together in this pull request.  Please remove the changes to compare composite transforms from the added tests.

That is fixed now!


[evergreen-travis] Update .travis.yml node versions

This is an automated PR, by the evergreen-travis project.
It helps you to keep the versions of node in your travis CI configuration up to date with new releases.

If you do not want to receive these PRs then remove your repository from our repository list
If there is a problem with the generated travis.yml, or something isn't right with this PR then please raise an issue

Coverage remained the same at 100.0% when pulling 9b29e3f1f45f90d15e8868bebe22c6446846957c on evergreen-travis:evergreen-travis-1479401532347 into fe96261beda1891f946e7cb8256dc92ce362af89 on Kikobeats:master.


Added new BOMB sound.

Existing

Pattern0 - BGM
Pattern9 - Start screen music
Pattern14 - Swap Position
pattern15 - a faster version of the game music we have already
pattern19 - Faster version start music
Pattern20 - Line Clear (3 or more are aligned and removed from the board)
Pattern21 - Object select
Pattern22 - shown during game over.
Pattern23 - Invalid move (NG sound)
Pattern24 - BOMB1

New

Pattern25 - BOMB2

Used Pattern List

Thank you!


[bug] CLI should obey value set in LOG_LEVEL environment variable

Current Behavior
Currently, if the LOG_LEVEL environment variable is set to any string value then dbt-bouncer will always run at the logging.DEBUG level:
https://github.com/godatadriven/dbt-bouncer/blob/b53a05be47e503206a713dc3864cfb15b0bbb64d/src/dbt_bouncer/logger.py#L51-L54
Expected Behavior
dbt-bouncer should obey the value of the LOG_LEVEL variable. If LOG_LEVEL=INFO is set in my environment then I would expect the dbt-bouncer logger to emit only INFO statements -- currently it will emit at the DEBUG level.
Steps To Reproduce

Set LOG_LEVEL=INFO in the environment.
run dbt-bouncer. Observe the DEBUG logging.
unset LOG_LEVEL
run dbt-bouncer Observe INFO logging.

Relevant log output
No response
Environment
- OS: MacOS Sequoia 15.1 (beta)
- Python: 3.10.15
- dbt-bouncer: 1.3.3

Thanks @gofford! Fixed in #281 and released in 1.3.4.


Curriculum update needed on advanced_selectors.md

The Odin's file, advanced_selectors.md is updated. Please update the Kampus' file, checkout file here advanced_selectors.md
Latest commits:

Clarify sibbling selectors and lint (#27176) (additions: 35, deletions: 37) on Jan 23 2024, 24:22 UTC

New commits have been made to the Odin's file. Please update the Kampus' file.
Latest commits:

Remove words intermediate html css (additions: 1, deletions: 1) on Feb 10 2024, 07:27 UTC

New commits have been made to the Odin's file. Please update the Kampus' file.
Latest commits:

Merge branch 'main' into patch-25 (additions: 1, deletions: 1) on Feb 11 2024, 21:45 UTC
Update advanced_selectors.md (additions: 6, deletions: 4) on Feb 9 2024, 21:17 UTC

New commits have been made to the Odin's file. Please update the Kampus' file.
Latest commits:

Intermediate HTML and CSS: Update descriptive links (#27822) (additions: 6, deletions: 6) on Apr 19 2024, 20:07 UTC

New commits have been made to the Odin's file. Please update the Kampus' file.
Latest commits:

Advanced Selectors - Intermediate HTML and CSS Course: suggest article usage (#27887) (additions: 2, deletions: 2) on Apr 30 2024, 12:14 UTC

New commits have been made to the Odin's file. Please update the Kampus' file.
Latest commits:

Positioning: Typo fix (#27943) (additions: 1, deletions: 1) on May 7 2024, 18:46 UTC

New commits have been made to the Odin's file. Please update the Kampus' file.
Latest commits:

Set default content (#28172) (additions: 7, deletions: 3) on Jun 14 2024, 16:48 UTC


Dotnet SDK Upgrade for azure stack hci 2022-05-01 release

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

Can you update the changelog if you plan to release the package?


0  I want to develop a Trading View Indicator in which the Candle turns Blue if TR<ATR. I tried the below code but no result.

//@version=5
indicator("TR < ATR Color Change", overlay=true)
// Calculate True Range (TR)
tr = math.abs(high - low)
tr += math.max(math.abs(high - close), math.abs(low - close))
// Calculate Average True Range (ATR)
atr = math.avg(tr, 14) // Adjust the period as needed
// Define coloring condition
color = if tr < atr
color.blue
else
color.maroon
// Plot the candles with coloring
plotcandle(close, high, low, open, color=color, wickcolor=color)

Ask your question in Pinescript Telegram channel. They will help you.


update dependencies

Prerequisites:

[x] Unless it is a hotfix it should be merged against the dev branch
[x] Branch is up-to-date with the branch to be merged with, i.e. dev
[x] Build is successful
[x] Code is cleaned up and formatted

Summary
updates and upgrades the current dependencies:
noticeable changes

vega-lite v5
husky 5
webpack 5

Are there any notable improvements or features code or UI wise with these upgrades?

I assume mainly performance improvements.


Remove reference to 'GOV.UK page'

Mentioning 'on a GOV.UK page' here:

Use the button component to help users carry out an action on a GOV.UK page like starting an application or saving their information.

...seems confusing to me. It’s not clear whether that includes services using a *.service.gov.uk domain or not. End-users might perceive everything to be "GOV.UK" but within government it seems common to refer to GOV.UK as being the content platform only, not the services.
I think it might be clearer to drop this reference, which would also be more consistent with other component descriptions.

You can preview this change here:
Built with commit eb634a52dd5d658db9e284ac257e06e1df2184f6
https://deploy-preview-1083--govuk-design-system-preview.netlify.com

Looks good to me, thanks @frankieroberto