RFC: Use buildExpression to promote substring parsers to UTF-8

This PR introduces substantial changes to parser builder block behavior, which may not be quite right yet, but we think it's a step in the right direction to make the library much more approachable.
First, it adds an empty ParserBuilder.buildBlock(), so that this is now valid:
let parser = Parse {}

This defaults to an Always<Substring.UTF8View, Void> parser. A small win, but friendlier.
Second, and more substantially, it adds buildExpressions to both ParserBuilder and OneOfBuilder, defined such that when a Substring parser is encountered, it automatically converts it to a Substring.UTF8View parser by wrapping it in FromSubstring.
This allows you to work with parsers on either layer freely without needing to explicitly use FromUTF8 or FromSubstring:
let parser = Parse {
  "caf".utf8  // parse quickly from UTF-8
  "é"         // parse all representations of é
}

This change also allows us to simplify a bunch of parsers. We can get rid of a bunch of interfaces that were there to simply wrap a parser in a FromSubstring (Int.parser(), Double.parser(), etc.), and we can get rid of an extra generic on parsers that only needed them to move between the parser's input type and the underlying bytes (Whitespace, Digits, etc.), and a bunch of simple parsers that were previously ambiguous now compile.
For example, @haikusw and @andreweades have pointed out that library newcomers quickly meet compiler error walls when first dabbling. Simple parsers where the Input is not known currently fail to compile:
Parse { // 🛑 Type of expression is ambiguous without more context
  Int.parser()
}

Parse { // 🛑 Type of expression is ambiguous without more context
  Whitespace()
}

And the only workaround thus far has been to make the input explicit, which is not ideal:
Parse {
  Int.parser(of: Substring.self)
}
// or
Parse {
  ""
  Int.parser()
}

But with this PR's changes these simple cases now compile just fine:
Parse {
  Int.parser()
}
Parse {
  Whitespace()
}

While all of these results are promising, it does force you to rethink what kind of a parser a parser is. It's no longer correct to look at a Parse block and think "this is a substring parser" or "this is a UTF-8 parser". Instead, it's a UTF-8 parser by default (unless you're working with an entirely different input type).
Before, it was common to work on the substring level and let the library automatically dip down into UTF-8 where appropriate, but this PR kind of "inverts" things. The end call sight should look the same, though (parser.parse(string)), so we're not sure if this change is negative. (We could make the default layer Substring instead, and buildExpression could automatically wrap UTF-8 parsers in FromUTF8, but we were worried this would negatively impact performance...this may be worth actually benchmarking, though, as it's probably a slightly better end-user experience.)
This change is potentially quite impactful, so we'd like to measure how it affects others before merging. I'd like to tag a few more active library users to get their opinion on the change, and maybe see if it negatively impacts any of their projects:

@finestructure
@iampatbrown
@MaxDesiatov
@randomeizer
@tgrapperon

Thanks for the heads-up, Stephen! I'll see if I can try out the changes with a one of our repos.
I've had a quick look through our Swift Package Index dependency data and these are the repos we're currently tracking as using swift-parsing:

https://github.com/alexanderwe/ConventionalCommitsKit.git
https://github.com/alexanderwe/SemanticVersioningKit.git
https://github.com/bradhowes/swift-math-parser.git
https://github.com/SwiftPackageIndex/ReleaseNotes.git

plus

https://github.com/SwiftPackageIndex/SwiftPackageIndex-Server.git

itself, which isn't in the index :)
Thought I'd share that in case you want to reach out to more users!

Checked out my various parsing test project, including some early ones were I was very confused :).
Really nice to be able to replace this:
let skippedWhitespace =  Skip<FromUTF8View<Substring, Whitespace<Substring.UTF8View>>> { FromUTF8View { Whitespace() } }
with:
let skippedWhitespace =  Skip { Whitespace() }
!!!
As I noted next to your comment about it, having to append .utf8 to every input passed to a parse(&inoutInput) was a bit annoying.  If that can be enhanced it would reduce the "huh?!" new users of this face.

Really nice to be able to replace this:
let skippedWhitespace = Skip<FromUTF8View<Substring, Whitespace<Substring.UTF8View>>> { FromUTF8View { Whitespace() } }
with:
let skippedWhitespace = Skip { Whitespace() }

😄
@haikusw Another thing to note is that Whitespace was recently changed to be skipping/Void by default, since it's less common to care about the underlying "trivia" unless you're building something like SwiftSyntax, which wants to preserve that info.
(In case you do want to preserve that info, there's a new Consumed parser that can capture the consumed input of another parser, e.g., Consumed { Whitespace() }.)

@stephencelis Thanks.  That does sound useful (!) and your SwiftSyntax example is a great one to keep in mind when working on this package/library.
I actually have my own whitespace and skippedWhitespace parsers defined to match a language grammar (which, interestingly, isn't as all encompassing as the new Whitespace parser in this library 🤔), but I had that old definition above that you helped me get working sitting in a comment in a playground, so I thought I'd switch back to that and see if this PR made the 🤯 go away.  Did! 🎉

I've converted this to a draft for now. While it solves real issues with the existing state of things, it introduces a layer of magic that I don't think we're comfortable with.
The core issue at hand is a Swift result builder bug. To work around the bug, we introduce overloads for specific common inputs (like Substring and Substring.UTF8View). These overloads make unambiguous parser builder blocks work great, but introduce ambiguity for simple parser builder blocks.
So this PR is really a workaround for a problem with a workaround for a problem...and this workaround introduces its own problems! 😵
So we think the correct path forward is to maybe close this and wait for the Swift bug to be fixed, instead. Then we can remove our original workaround, which should solve the problem this workaround intended to solve :laughing:

Aw…. sad to revert my projects changes to try this branch, but hopefully we can get that bug fixed sooner than later.  I just upvoted it and maybe others will also.

Is there a simpler example that can demonstrate the bug?  I find the one in that bug report pretty brain-bending.  Just wondering if a simpler/clearer example might help get it addressed sooner.

@haikusw The example is definitely abstract, but I'm not sure it can get simpler. We can make it a lil more complex but understandable by renaming a few things:
struct Parser<Input> {}

@resultBuilder
enum ParserBuilder {
  static func buildBlock<Input>(_ components: Foo<Input>...) -> Foo<Input> {
    .init()
  }
}

func parse<Input>(@ParserBuilder build: () -> Parser) -> Parser {
  build()
}

parse {
  Parser<Substring>()
  Parser() // 🛑
}

error: Cannot convert value of type 'Parser<_>' to expected argument type 'Parser'

Basically, when you're in a builder context, generics aren't inferred the same way they'd be elsewhere:
let parsers = [
  Parser<Substring>(),
  Parser() // ✅
]

Turns out this isn't a bug, unfortunately. @iampatbrown turned my attention to this post: https://forums.swift.org/t/function-builder-cannot-infer-generic-parameters-even-though-direct-call-to-buildblock-can/35886/15

Thanks.  I finally ate an overly delayed breakfast and my brain restarted :)  <whew!>
Realized it was mostly naming that was making my brain tie itself in knots, and that the enum was being used as an un-creatable type as a namespace.
Get back and that's exactly what you improved above.  Thanks.
The other thing that made me think ("why is that here?") was fully specified one.  Now I see that it's to show what the compiler needs to succeed.  Maybe a comment on that line  saying "// fully specified works, but shouldn't be necessary" or something.
Probably the Swift compiler devs are so deep in this stuff that your example is completely legible to them :)
Cheers

Turns out this isn't a bug, unfortunately. @iampatbrown turned my attention to this post: https://forums.swift.org/t/function-builder-cannot-infer-generic-parameters-even-though-direct-call-to-buildblock-can/35886/15

🤔

That thread was interesting.  The discussion towards the end between John and Douglas and Matthew was interesting.  Not sure it applies to the issue Parsing has though.  Also sounded like it's uncharted territory in terms of compiler performance impact.
Does this mean that dropping the chaining style syntax may want to be reconsidered?
Or maybe it's that this PR gets reconsidered since that Swift "bug" is a design decision?
It's cool how much you guys do work that so often pushes up against the limits of Swift.

Looks like that discussion was about:

static func buildExpression(_ expression: Expression) -> Component
Builds a partial result from an expression. You can implement this method to perform preprocessing—for example, converting expressions to an internal type—or to provide additional information for type inference at use sites.

From: https://docs.swift.org/swift-book/ReferenceManual/Attributes.html#ID633

I have no idea if this works, but it now compiles :)
struct Parser<Input> {}

@resultBuilder
enum ParserBuilder<Input> {
  static func buildBlock(_ parsers: Parser<Input>...) -> Parser<Input> {
    .init()
  }
  static func buildExpression(_ expression: Parser<Input>) -> Parser<Input> {
    return expression
  }
}

func parse<Input>(@ParserBuilder<Input> build: () -> Parser<Input>) -> Parser<Input> {
  build()
}

parse {
  Parser<Substring>()
  Parser()
}

Deleted comments that basically got back to what you did in this PR - use buildExpression like they talked about in that thread.   That thread makes it seem like the approach in this PR is what they expect one to do, especially given this from the documentation:

static func buildExpression(_ expression: Expression) -> Component
Builds a partial result from an expression. You can implement this method to perform preprocessing—for example, converting expressions to an internal type—or to provide additional information for type inference at use sites.

@haikusw I think buildExpression might be the right tool for the job here, but I don't think we're using it the right way, yet.
John McCall seems to suggest that parameterizing the builder with a generic (like @ParserBuilder<Input>) could be a workaround. I'm going to see how far I can take it.

Cool!
I did this to your more grokable bug sample from above:
struct Parser<Input> {}

@resultBuilder
enum ParserBuilder<Input> {
  static func buildBlock(_ parsers: Parser<Input>...) -> Parser<Input> {
    .init()
  }
  static func buildExpression(_ expression: Parser<Input>) -> Parser<Input> {
    return expression
  }
}

func parse<Input>(@ParserBuilder<Input> build: () -> Parser<Input>) -> Parser<Input> {
  build()
}

parse {
  Parser<Substring>()
  Parser()
}

and the compiler liked it :)
(FWTW)

This seems like a really good change to me!
Most Swift users aren't familiar at all with all the different string flavours - I myself only discovered UTF8View, UnicodeScalarView, et. al from your video series. Juggling with all these different kinds of Strings is definitely the biggest impedance to my productivity with swift-parsing. What this change would allow us to now say is: "Mark all your strings in your parsers with .utf8 unless there are any weird characters" (basically any non-ASCII characters). I personally find that quite powerful, and a huge plus from a usability standpoint.
As you mentioned above, what we thought was a bug is unfortunately not a bug, and the proposed solution by John McCall doesn't seem optimal.
I personally don't see this as a layer of magic, but instead as an opinion taken by the library to promote performance --- and not really at the cost of correctness since users would have needed to wrap their "weird characters" in 'FromSubstring' anyways if they were to use UTF8View anyways.

John McCall seems to suggest that parameterizing the builder with a generic (like @ParserBuilder) could be a workaround. I'm going to see how far I can take it.

@stephencelis, I used this approach in a few of my projects/experiments with result builders, most likely for this reason. For example, the EffectBuilder from TCA's #1019 as initially generic over the Action and Failure before being nested in Effect to inherit these generics (with would require a bunch of where Action == … otherwise). I've also used one in the protocolized refactor of my swift-measure benchmark library which is not public yet (and where the Experiment protocol I introduced is very similar to Parser, with some Input and Output).
I've ended up making this ExperimentBuilder not generic because it wasn't pairing well with the kind of call site syntax I aimed: If I recall correctly, it was similar to a chicken or egg problem, and I had to qualify the generics at the equivalent of the Parse level to make it compile (which I wanted the avoid). The last time I've tried, it was with Swift 5.5, but Swift 5.6 is better at resolving types so it may work better now. And maybe qualifying the Input of top levelParses is acceptable after all, as we're already doing it frequently with their first block instead.
I kept using a parametric builder for EffectBuilder because this one was used in places where the generics could be inferred to match the Reducer expected output.
I've noticed that these generic builders are slightly less convenient to reuse, as they often require writing the generics twice in the function declaration.
This is mostly my personal recollection of previous experiments with parametric builders. I'll give it a new spin with ParserBuilders to check if it improved or something new clicks.
It is also possible that the new Reducing blocks likely expected in Swift 5.7 can support the generic propagation between blocks, but I didn't experiment with them yet.
I'm also remembering that result builders can be defined using protocols. This allows to compose/specialize behaviors, so maybe a UTF8ParserBuilder: ParserBuilder could help solving the PR's issue, but this would require many overloads in built-in parser's definitions.

@tgrapperon I have a branch (unpushed) that is both promising and frustrating. It solves the generic inference issues but I believe the generic and/or buildExpressions introduce regressions in type-checking that make something like the user CSV parser fail to parse in time (due to the overload space of String.init and .map(String.init)).
I'll try to push something that works but has had to refactor around these regressions tomorrow, if you're interested in taking a stab at things.

It is also possible that the new Reducing blocks likely expected in Swift 5.7 can support the generic propagation between blocks, but I didn't experiment with them yet.

While this could potentially be true (according to evolution lore), it didn't appear to be the case in my brief testing. I commented in the proposal review today: https://forums.swift.org/t/se-0348-buildpartialblock-for-result-builders/56143/24

I will have a play with it in a branch of hsdoc shortly. I need to update it to the latest main anyway, will start with that and then play here.
Having not looked at the code, I'm ok in principle with trying to make it easier to use the more efficient utf8 approach. Like others here, this series was the first encounter I had with it, and it's not necessarily intuitively clear that a UTF-8 collection will not necessarily be a 1-to-1 byte count with the number of characters that end up on your screen. I get it, but largely because I've written a UTF-8/UTF-16 parser (in a different language) in the past.
In some ways, it's the layers/alternative ways of dealing with different abstractions of character strings that makes the library more complicated. Not much that can be done about that, particularly if writing custom parsers. It is probably something that's worth writing a documentation page about specifically. Going from String to Substring to a collection of UTF characters. (This may already exist, I haven't had a chance to review the new DocC articles yet)
Anyway, will update when I get a chance to kick the tires.

both promising and frustrating

@stephencelis This is the experience I had, and why I finally concluded at the time that "the less generic/specialized the builder, the better". But it may be possible to reach something nice with more effort than I invested.
I'm traveling and I missed that buildPartialBlock entered official review. This is great news. I was aware of the one-way constraint behavior (albeit not the naming): I think Becca Royal Gordon mention it in her WWDC talk when writing the equivalent/intermediary representation of the blocks as individual statements, but I was hoping that the buildPartialBlock would provide enough structure to enforce some type along the blocks chain. It looks very unlikely from what I'm understanding now.
I have some wild ideas to check, but I'll experiment more before drowning you with nonsense.

@tgrapperon I spun up a build-expression-2 branch that introduces a generic to ParserBuilder and OneOfBuilder, but type-checking gets bogged down quickly to the point of the library being unusable.
You can see this by running OneOfTests.testJSON, where this expression takes 5 seconds to type check for me:
https://github.com/pointfreeco/swift-parsing/blob/build-expression-2/Tests/ParsingTests/OneOfTests.swift#L212-L222
(10 seconds with the final parser commented in.)
Whereas on main it builds pretty much instantaneously.
The string parser just below fails to compile after 60 seconds of trying.
So I'm not too confident this approach is going to work, unfortunately. I thought maybe the many generated Zips was making things worse, but when I tested the simpler buildPartialBlock approach, type-checking speeds were more or less the same (awful).
Putting ParserBuilder<Input> aside for a moment, I don't even think the enhanced buildPartialBlock with better type inference would help us here, since one-way constraints would still mean that the first parser in a builder block would need to build in isolation.
Parse {  // What is this parser's `Input`?
  Int.parser()
}

So I don't think that feature would help us, either.
In the end I'm wondering if the best we're going to get is when we can define parsers in a SwiftUI-like fashion:
struct QuotedField: ParserPrinter {
  var body: some ParserPrinter<Substring, Substring> {
    "\""
    Prefix { $0 != "\"" }
    "\""
  }
}

If the default way to build a parser involves the ceremony of introducing a type and scope where the Input is fully-determined, the opportunity for ambiguity disappears.

After a bunch more experimentation, we've surfaced what appear to be bugs with parameterized result builders that are blocking:

SR-16088: Parameterized result builder breaks type inference
SR-16090: Nested parameterized result builders are slow

Should these issues be fixed, there's could be a nice inference story for the future of swift-parsing via a SwiftUI-like interface, where Input is always made explicit.
If anyone is interested in seeing them fixed, please feel free to upvote them on JIRA.

@tgrapperon Thanks for exploring and letting us know! I'm not quite sure if separating the parser from the DSL is possible, or if it would solve the type inference issues we are seeing, but if you come up with anything interesting we'd love to see it!

I've also posted to the forums to ask about the issues we were seeing with generic result builders: https://forums.swift.org/t/result-builder-expressiveness-and-type-inference/56417

After a bunch more experimentation, we've surfaced what appear to be bugs with parameterized result builders that are blocking:

SR-16088: Parameterized result builder breaks type inference
SR-16090: Nested parameterized result builders are slow

Should these issues be fixed, there's could be a nice inference story for the future of swift-parsing via a SwiftUI-like interface, where Input is always made explicit.
If anyone is interested in seeing them fixed, please feel free to upvote them on JIRA.

Thanks!  Upvoted.
Curious about the gist you posted
I don't have the current snapshot with the experimental feature, but found the pitch.  Sounds like a comment in that pitch about these two bugs would be apropos? Especially since you were so enthusiastic in your comment there :)

Well so much for hoping it was in the WIP implementation of buildPartialBlock support and thus easier to get fixed… :-/
Thanks.

It's uncanny how often you guys push the Swift compiler and either find bugs or language limitations… 🧙♂

It's uncanny how often you guys push the Swift compiler and either find bugs or language limitations… 🧙♂

Wonder if Apple should hire us to QA 😆

Closing this for now. It was an interesting experiment but we're not going to commit to such change right now :smile:


Add a sample editorTheme object to settings.js

Added a commented-out sample of the editorTheme object, which allows changing the page title, icon, and app logo.

Coverage decreased (-0.1%) to 88.267% when pulling 9bcc5819ae69ecede785468f3cb5004e9635b1aa on JesseNaranjo:settings.js-editorTheme-sample into d3be1f1e2c859e4f8ecde817a65fffc466c80e3b on node-red:master.

We purposefully left this out of the default settings file as it is not an option that 'normal' users will touch.
The concern of filling the settings file with every single possible option is it then makes it hard for a user to find the things they actually need to use.
What is really needed is a section in the docs and a worked example of its use.

@JesseNaranjo hi there - tidying up some PRs. This is good to merge, just need you to sign the updated JS Foundation CLA - if you're still interested - https://cla.js.foundation/node-red/node-red?pullRequest=924
Otherwise happy to manually add this in.

We added a very minimal editorTheme option to the settings file a while ago. It isn't an option we expect most individual end users to make use of, so not going to flood the settings file with an example of all the various options it exposes.


this.fetch is not a function

When trying to generate an image, I get this error:
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]: TypeError: this.fetch is not a function
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at Replicate.request (/home/insomnia/lemmy-art-bot/node_modules/.pnpm/replicate@0.11.1/node_modules/replicate/index.js:147:33)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at Replicate.createPrediction<EMAIL_ADDRESS>May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at Replicate.run (/home/insomnia/lemmy-art-bot/node_modules/.pnpm/replicate@0.11.1/node_modules/replicate/index.js:103:47)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at generateArt (/home/insomnia/lemmy-art-bot/bot.ts:26:13)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at Object.<anonymous> (/home/insomnia/lemmy-art-bot/bot.ts:83:29)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at Generator.next (<anonymous>)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at /home/insomnia/lemmy-art-bot/bot.ts:31:71
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at new Promise (<anonymous>)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at __awaiter (/home/insomnia/lemmy-art-bot/bot.ts:27:12)
May 11 20:37:11 lemmygrad-art-bot pnpm[42126]:     at Object.mention [as handle] (/home/insomnia/lemmy-art-bot/bot.ts:78:20)

I have no idea why this is happening. I'm running on Node 18.16.0, so fetch should be defined. I also made sure that my API key is correct. Here is how I am using the library:
const replicate = new Replicate({
  auth: API_KEY,
});

const generateArt = (prompt: string) =>
  replicate.run(
    'ai-forever/kandinsky-2:601eea49d49003e6ea75a11527209c4f510a93e2112c969d548fbb45b9c4f19f',
    {
      input: {
        prompt,
        width: 768,
        height: 768,
        batch_size: 3,
      },
    }
  );

I tried passing in an option for fetch to the constructor, but it didn't show up in the typescript types.

I just updated to 0.12.1 and used cross-fetch for the fetch option. It works now. Thank you!

@SleeplessOne1917 how u solve this?

@Rafazeon The README has instructions about how to configure fetch here: https://github.com/replicate/replicate-javascript#constructor

The client makes requests to Replicate's API using
fetch.
By default, the globalThis.fetch function is used,
which is available on Node.js 18 and later,
as well as
Cloudflare Workers,
Vercel Edge Functions,
and other environments.
On earlier versions of Node.js
and other environments where global fetch isn't available,
you can install a fetch function from an external package like
cross-fetch
and pass it to the fetch option in the constructor.
import Replicate from "replicate";
import fetch from "cross-fetch";

const replicate = new Replicate({
  // get your token from https://replicate.com/account
  auth: process.env.REPLICATE_API_TOKEN,
  fetch: fetch,
});


%2e Being Decoded in URL

Hi there,
When a url-encoded period is included in a url (in path directory, path file, param name, or param value), it gets permanently converted to a period before the request is made (sometime before get_connection() is called in a subclassed HTTPAdapter). Other url-encoded things like single ticks (%27), double quotes (%22), semicolons (%3f), and percent symbols (%25) don't get decoded.
This means you can't successfully request a url with %2e anywhere in it because it gets changed to a '.', and if you try to double-url-encode it with %252e, it stays as %252e.
I've also tried passing %2e in via params=dict(...) and params='...bytes...', and nothing works.
Examples:
requests.get('http://www.example.com/test.x%252ey/test.%252ey.html?test.x%252ey=test.x%252ey').url
Output: u'http://www.example.com/test.x%252ey/test.%252ey.html?test.x%252ey=test.x%252ey'
First Line of Request When Viewing Through Proxy: GET /test.x%252ey/test.%252ey.html?test.x%252ey=test.x%252ey HTTP/1.1
requests.get('http://www.example.com/', params=dict(a='x%2ey')).url
Output: u'http://www.example.com/?a=x%252ey'
First Line of Request When Viewing Through Proxy: GET /?a=x%252ey HTTP/1.1
requests.get('http://www.example.com/', params='a=x%2ey').url
Output: u'http://www.example.com/?a=x.y'
First Line of Request When Viewing Through Proxy: GET /?a=x.y HTTP/1.1
requests.get('http://www.example.com/', params='a=x.y').url
Output: u'http://www.example.com/?a=x.y'
First Line of Request When Viewing Through Proxy: GET /?a=x.y HTTP/1.1
I just happen to be facing a use case where I need to be able to make a request containing a %2e in one of the parameters, so I'm a bit stuck on how to workaround this within the context of the Requests lib.
Best Regards,
-Justin

Thanks for this @correcthorsebatterystaple-!
Requests has strong opinions about the correct form of a URL: specifically, it does not percent-encode things that don't normally need percent encoding. I should note that your server is in this instance misbehaving: periods do not need to be percent encoded in query string and there's no reason to do it, and even if there were, for characters that do not need percent encoding both the encoded and non-encoded character are to be treated exactly identically.
Regardless, the pragmatic solution to this problem is the prepared request flow, where you construct a Request object, prepare() it, and then edit the url field on the PreparedRequest object you get. Any changes to the URL field will then be kept, so you can (for example) double-encode the period in the query string and then do a prepped.url.replace() call to swap it out with the single-encoded period.

Thanks for the response, @Lukasa.
Fair point regarding equivalency and the server misbehaving. However, one doesn't always have control over the misbehaving server, so sometimes you have to have a way to send what needs to be sent, even if it's technically wrong. :-)
Thanks for the info on how to get around this with a PreparedRequest!
Out of curiosity, I understand a stance of not percent-encoding things that don't typically need it, but why percent-_de_code things (specifically the period in this case)? Does it benefit other parts of the codebase by normalizing encoded and decoded periods when performing operations?
Also, regarding Requests' stance on URL forms and encodings, is there documentation regarding what gets encoded/decoded where? For example, I noticed passing query string params as a dict results in encoding, but passing as bytes doesn't.
I'm mainly asking because I'm writing a tool that walks through a series of requests (to and from servers I don't have any control over ;-) ), and part of the challenge is to ensure certain pieces of data pass through the process in their intended form. If I pull a URL out of a Location header, for example, do I need to do any manually encoding on certain characters before I pass it to Requests (like plus signs)?
Thank you for your time on this! I'm a bit of a Python noob (maybe I've graduated to noob+ at this point ;-) ), and I'm even more of a Requests noob, so I appreciate you taking the time to field my feedback.

Why percent-decode things (specifically the period in this case)? Does it benefit other parts of the codebase by normalizing encoded and decoded periods when performing operations?

The short answer is because we try to normalise URLs. This is because users are often inconsistent with their percent encoding, leading to URLs that are partially encoded and partially not. That causes problems when we want to come to percent-encode a URL ourselves, because blindly percent-encoding a URL that may be either unencoded, encoded, or partially encoded can lead to all kinds of nasty results. The easiest way to resolve the problem is to do what we currently do, which is decode the URL (ignoring unencoded values rather than treating them as errors) and then re-encoding it according to the standard encoding rules.
Generally speaking, Requests reserves the right to transform your request into a form that is semantically identical to the original in order to provide a better user experience for the majority of users: essentially, we try to save users from themselves at the cost of making it harder to be really specific about what you want.

If I pull a URL out of a Location header, for example, do I need to do any manually encoding on certain characters before I pass it to Requests (like plus signs)?

You don't need to, but you may want to manually handle it yourself if you need it to remain identical to the Location header provided.

And this is exactly why PreparedRequests were created.

Right on. Thanks!


[Feature Request] Works with private Github repos

I am able to deploy a container from a private Github repo.

You mean you are able to, or you want it to?
This won't be easy, if possible for all. Open in Cloud Shell experience creates an incognito shell where there's no such credentials to get private Git repos.
So, Cloud Run Button is great for deploying off-the-shelf (i.e. public software) without knowing much about GCP, Cloud Run etc. However, for things that you’ve written for yourself, you should probably consider https://console.cloud.google.com/run UI or gcloud run deploy/gcloud run services replace command.
I'm eager to hear use cases. But if you're the person writing the code (i.e. private repo), there's no a lot this button can do for you and we have deployment experiences.

Ah I see thanks for the explanation. A data scientist really like the no fuss approach of the button, but works only in private repos.

Yeah I would redirect them to Cloud Run quickstarts/tutorials for self-serve.


Framework support

Hello,
I've added a framework target support (for those people who're using ObjC with Carthage as dependency manager, like me).
This step required migration to Xcode 7.3, so, please, review thoroughly, if possible.
Thanks in advance!

Thank you very much for the pull request!
However, libextobjc is emphatically not meant to be used wholesale. The features haven't really been tested to see if they combine well together, and I expect that most projects will only want two or three modules (not all of them).
Even the features which are not "experimental" may be undesirable for a lot of projects—for example, how many do you know that really want coroutines? 😉
I appreciate the effort here, but I think this would encourage the wrong kind of usage of libextobjc code. Feel free to maintain a framework on a fork, though! ☺


Scene Layers & Web Scenes

AGO Assistant does not seem to support Scene Layers or Web Scene items.  Is this something that can be added?

Yes, it's a fairly easy fix. Basically, there's a whitelist of item types that can be copied. In its current state, the app can copy anything that is non-file based. I need to update the whitelist to reflect the latest set of item types as documented here.
Eventually, I'd like to move the whitelist to a config file, but for now you can find it here.


When HEAD is ahead of remote, "Newer on Server" flag is incorrectly set

I'm very new to this codebase but I know git fairly well and I had a really weird problem where, because I had an unpushed change to a file in my local repo, in UE4 no changes to that file would ever show up in the Submit Changes dialog.
The problem is that when the plugin deems there's a newer file on the server, it excludes the file from being able to be checked in (silently). I picked through the debug and tracked down the bug to this code (line 1088, GitSourceControlUtils.cpp):
TArray<FString> ParametersDiff;
ParametersDiff.Add(TEXT("--name-only"));
ParametersDiff.Add(bDiffAgainstRemote ? FString::Printf(TEXT("origin/%s "), *BranchName) : BranchName);
ParametersDiff.Add(TEXT("HEAD"));
const bool bResultDiff = RunCommand(TEXT("diff"), InPathToGitBinary, InRepositoryRoot, ParametersDiff, OnePath, Results, ErrorMessages);
OutErrorMessages.Append(ErrorMessages);
if (bResultDiff)
{
    for (const FString& NewerFileName : Results)
    {
        const FString NewerFilePath = FPaths::ConvertRelativePathToFull(InRepositoryRoot, NewerFileName);

        // Find existing corresponding file state to update it (not found would mean new file or not in the current path)
        if (FGitSourceControlState* FileStatePtr = OutStates.FindByPredicate([NewerFilePath](FGitSourceControlState& FileState) { return FileState.LocalFilename == NewerFilePath; }))
        {
            FileStatePtr->bNewerVersionOnServer = true;
        }
    }
}

This is running git diff --name-only origin/master HEAD. The problem is that this will report all changes in HEAD which haven't been pushed to origin/master yet, as well as any changes in the other direction. So it's not detecting that the file is newer on the server, just that they're different. It's impossible to get out of this situation without manually pushing, and you wouldn't know to do that because there's no information in the UI, just "No assets to check in!".
Git Diff can only compare 2 revisions without any reference to their ancestry. To truly detect whether there's a newer change on the server, you need to run something that accesses the history, like git log, or git rev-list. They both work but both have slightly different extra output you have to ignore
There are 2 things that could work:

git rev-list --objects HEAD..origin/master

This gives you the changed files but unfortunately also all the objects leading up to it so there's some kruft to sift through.

git log --oneline --name-only HEAD..origin/master

This output is a little more familiar since it's the same as git status --porcelain but it does also include a line per commit as well, which would need to be ignored.
I'm not productive enough in this codebase to submit a PR for this yet, because of the parsing changes needed, sorry. But I thought I'd let you know.

Also a nice way of not having to look up the branch is to use HEAD..HEAD@{upstream} as the range.

Actually I figured out how to do it, using --pretty= to omit the commit line, so the previous parsing code works OK. Submitted PR #135


Ontology files can use a format update

Justification and suggestions will follow in not too long.

The need to update the format was discussed a couple of months ago.  Some of the justifications were

An ontology editor was being added to Causemos and the present format does/did not work well for that task (IIRC).
We need/want to support metatdata on non-leaf nodes.  Eidos has a branch in which this is implemented, but in a way that changes the ontology format in the smallest possible way, which isn't very clean.
The present version is somewhat difficult to work with in that the keys are not fixed.  Some of them are the actual names of nodes and don't come from a small, fixed list.  They might rather be the values.  In this example, anything in front of a colon should come from a fixed set:

  - livestock_production_inputs:
    - OntologyNode:
       examples:
       - livestock feed
       name: livestock_feed

The minimal indentation makes working with long files a little difficult, like when browsing the file on github.

The format was discussed at UAz and our top choice looked like this:
- node:
    name: wm
    examples:
        - crime
    definition:
    polarity: -1
    semantic type: event
    children:
        - node:
            name: concept
            examples:
                - crime
            definition:

Nodes are all called node and names have been moved to the name field.
Children are explicitly listed under the children key.
Indentation has been increased to four spaces where before it was two and sometimes even zero.
Non-leaf nodes look just like the others except that they have no children.

At a recent meeting we discussed these points which are related to the ontology format:

We could add examples/definitions for specific compositions

Some compositions have more meaning than the individual parts
Currently no way to structurally add to the ontology - may need separate place to put these
Would also need support at the level of reading/grounding

The format might account for adding information to specific compositions.

I think the new proposed format should work well!

The proposed format looks good to me. Is there any reason why nodes are structured in a list rather than a dict? Is there an imaginable case of multiple nodes in the same branch having the same name? Why not:
wm:
    examples:
        - crime
    definition:
    polarity: -1
    semantic type: event
    children:
        concept:
            examples:
                - crime
            definition:

Just curious -- lists are fine with me.

It was my (false?) impression that the open vocabulary keys was a complication.  wm has examples, definition, polarity, semantic type, and children that can be known and listed in advance.  Children has a bunch of things whose names need to be collected in a very different way.  It's probably not a big deal but it seems like it would complicate the code (and I'll be checking on that shortly).  There are probably not naming conflicts among siblings, but I think there are cases in which the name of some great aunt is reused in some grand niece and if nodes get moved around there could be a problem.  However, using the key "name" but having the values conflict would probably be just as bad.  If that check is not already in the unit tests, I should add it.

Yeah I think with the way we parse the yml file it would be simpler to deal with lists than dicts.

FWIW it looks like the definition field should be called descriptions.

For that matter, it's probably a good time to change pattern to patterns.

I'm going to have to find out about this take_args that I see in the flat ontology.  Can anyone tell me about it?

We have not yet used it in production, but at one time there was also a request for negative examples and there is an old prototype for it.  If we do need these, I suggestion adding counterexamples and counterpatterns.


Witherspoon: CT Run and Evaluate logs and open issues accordingly

https://github.com/openbmc/openbmc-test-automation/issues/201
The pre poweron bringup is ready,

Maintained here https://github.com/openbmc/openbmc-test-automation/issues/220


Kafka producer should support SpEL expressions to indicate target topic

Hi Marius (@mbogoevici),
This is continuation of the [1] discussion.
Just to summarize my goal here. I'd like to be able to send message to HTTP endpoint [2] for example and specify target Kafka topic dynamically using HTTP header for example.
I think it might be indeed possible to handle bridging between HTTP app starter [2] and Kafka producer without dedicated Kafka sink component. Correct me if I'm wrong, but if we manage to change this [3] line to support SpEL expression (not only hardcoded LiteralExpression like now), then we should be able to specify target topic via expression.
Let's say that we introduce new property to indicate that certain binding should use SpEL expression (like spring.cloud.stream.bindings.output.destinationExpression=spel) instead of Literal (default). Then we should be able to specify destination dynamically:
spring.cloud.stream.bindings.output.destinationExpression=spel
spring.cloud.stream.bindings.output.destination=headers.target_topic

And in such case HTTP request coming to HTTP app starter should be routed to the topic indicated by target_topic HTTP header.
This is just hypothesis which might be wrong considering my limited Spring Cloud Stream expertise. :) What do you think about such approach, Marius?
[1] https://github.com/spring-cloud/spring-cloud-stream/issues/946
[2] https://github.com/spring-cloud-stream-app-starters/http
[3] https://github.com/spring-cloud/spring-cloud-stream-binder-kafka/blob/66eb15a8e2d90b1f593f19ddc07869b8d8b1d74c/spring-cloud-stream-binder-kafka/src/main/java/org/springframework/cloud/stream/binder/kafka/KafkaMessageChannelBinder.java#L373

Hi Henrik,
I believe things got a little crosswired here. Regarding the dynamic destination support, I still think that an can leverage the dynamic destination support which is the basis of the router sink: http://docs.spring.io/autorepo/docs/spring-cloud-stream-docs/Chelsea.SR1/reference/htmlsingle/#dynamicdestination  - which is what @markfisher was hinting here: https://github.com/spring-cloud/spring-cloud-stream/issues/946#issuecomment-299577574.
The original issue proposed two things:
a) that we support routing (which is where the paragraph above applies IMO)
b) that we support a SpEL expression for populating keys in the Kafka binder, which I think we should definitely do.
For a), it looks like a customized version of the http starter could help using the dynamic destination support. Making the destination a SpEL expression is possible, but requires some serious changes in the core. Populating the key could be easily done as an additional feature of the binder tho.
Let me know what you think.

Hi Marius,
Indeed BinderAwareChannelResolver seems to do the job when it comes to dynamic destinations. Kudos! :)
The other question if it is possible to take advantage of dynamic destinations in HTTP starter app, so we can use dynamic HTTP routing in Spring Cloud Data Flow without writing customized version HTTP starter for this purpose. But maybe let's try to focus on this later :) .
First things first - dynamic key expression support. :) So you have something like #131 in mind?

Hi Henryk,
Yes - I will close this issue in favour of creating a new issue - #134, since the current one mostly deals with dynamic topics.

Agreed! Many thanks, Marius.


Added paging support for storage list commands.

Closes: https://github.com/Azure/azure-cli/issues/3745
-"nextMarker" property added to every result of list output
-list commands now have --num-result and --marker as parameters.
-minor fixes, and added tests
This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[x] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

Command Guidelines

[x] Each command and parameter has a meaningful description.
[x] Each new command has a test.

(see Authoring Command Modules)

View a preview at https://prompt.ws/r/Azure/azure-cli/5419
This is an experimental preview for @microsoft users.

Please rebase. And does Aaron have any feedback of this?


Quoted column names in add column

G'day, there are some conflicts that need to be resolved.
Also you may want to look into using https://docs.rs/sqlparser/latest/sqlparser/keywords/constant.ALL_KEYWORDS.html to determine which words to quote, similar to what I did in https://github.com/Electron100/butane/pull/104
It is a bit of a personal preference thing, but I dislike seeing lots of unnecessary quotes.

Hi folks! I went ahead and made these changes directly to the code just now, thanks for opening a PR! Sorry I missed it :)
Regarding auto-quoting, given that these are all auto-generated queries ran by Reshape itself, I think it's fine to just quote the names directly!


feat: chips light theme and resume work summaries improvs

Current dependencies on/for this PR:

main

PR #108   👈

This comment was auto-generated by Graphite.


It takes about a minute to load camera preview for the first time when you start the app.. Is there anyway by which we can speed up this process? May be opencv library is taking time to load

Added in the reamde: "Note. Loading model sp68.dat is very heavy task, it can take several seconds or dozen seconds to be uploaded. You could try to retrain model and decrease size and therefore size of the application and initialization time."

Added in the reamde: "Note. Loading model sp68.dat is very heavy task, it can take several seconds or dozen seconds to be uploaded. You could try to retrain model and decrease size and therefore size of the application and initialization time."


fix: UI Utils library are no longer able to load the UI images

The UI Utils library fetches its template images from a server we’re hosting, that URL seems to still work. (e.i. image)
And it makes the this kind of UI error

It seems like it could be a CORS problem.

fixed in this MR


Migrate Lime on native platforms to use SDL3

SDL just released version 3.1.3 stable API preview, which means that (while the library still has bugs and issues to resolve before the 3.2 stable release), no existing functions will be removed, making it stable enough for migration.
There is a very long list of useful features that migrating would enable (see the list at the link), and also a long list of issues that are resolved by updating (such as #1569), but this first requires migrating the existing places that SDL2 are used.
I originally attempted this myself by just editing the existing implementation last year, but this resulted in a bunch of graphical glitches, so updating would probably require someone more experienced with C++ and graphics APIs.

Some features we may find relevant (now or in the future) include:

Using nanoseconds for timestamps in various places
Using OS timestamps for input events (rather than the SDL timestamp, making it way more accurate)
Replacing TinyFileDialog with a more flexible and well-maintained implementation
Support for clipboard data of any mime type
Improved audio stream handling
New storage and file-system APIs that work across platforms
The new SDL Graphics API, providing access to cross-platform graphics and compute.

Plus any fixes from newer versions of SDL 2.x.

I am willing to give a jab at this, since I'm interested in eventually allowing Stage3D from OpenFL to use SDL GPU and as far as I know 3.1.6 is already pretty usable. Will post updates as I get it working.

I am willing to give a jab at this since I'm interested in eventually allowing Stage3D from OpenFL to use SDL GPU and as far as I know 3.1.6 is already pretty usable. Will post updates as I get things to work.

Great to hear! I'm interested to know whether you think there will be major benefits to using SDL GPU over OpenGL

I am willing to give a jab at this since I'm interested in eventually allowing Stage3D from OpenFL to use SDL GPU and as far as I know 3.1.6 is already pretty usable. Will post updates as I get things to work.

Great to hear! I'm interested to know whether you think there will be major benefits to using SDL GPU over OpenGL
EDIT: @Fancy2209 Please check this out if you haven't: https://github.com/libsdl-org/SDL/blob/main/docs/README-migration.md

The major benefit I see in SDL3 is portability and being able to use Modern Graphics APIs
Instead of needing to maintain specific backends for platforms (like having a D3D12 backend for Xbox, GNM on PS4/5, Vulkan on Switch, GLES on Android, whatever whatever) lime could just keep the OpenGL/WebGL and the SDL GPU backend. SDL GPU could even allow WebGPU on Web as I believe that's a wip. Keep in mind I'm not a licensed console developer but I know maintaining the console versions has been an issue for lime before.
The other point is many people have been asking for OpenFL and Lime to support "modern" graphics APIs instead of OpenGL and I believe SDL GPU is the easiest way to do this, as it'll support GNM, D3D12, Vulkan and WebGPU with one API (Todo is to see if their shader cross library will allow us to not make a new AGAL Shader Translator)
Performance improvements I'm not sure, this will be a try it and see.
I'll first just port lime to SDL3 though, then look into GPU, as I believe the first thing will already be quite a big thing and I don't want to do an unreviewable PR.


Run hhsearch have not "t000_.atab"

detail:
Using backend: pytorch
Traceback (most recent call last):
File "/data1/home/RoseTTAFold-main/network/predict_e2e.py", line 324, in
pred.predict(args.a3m_fn, args.out_prefix, args.hhr, args.atab)
File "/data1/home/RoseTTAFold-main/network/predict_e2e.py", line 120, in predict
xyz_t, t1d, t0d = read_templates(L, ffdb, hhr_fn, atab_fn, n_templ=10)
File "/data1/home/RoseTTAFold-main/network/parsers.py", line 241, in read_templates
xyz_t, qmap, t0d, t1d, ids = parse_templates(ffdb, hhr_fn, atab_fn)
File "/data1/home/RoseTTAFold-main/network/parsers.py", line 180, in parse_templates
for l in open(infile, "r").readlines():
FileNotFoundError: [Errno 2] No such file or directory: '/data1/home/RoseTTAFold-main/example/t000_.atab'
what should I do?

which hhsuite version are you using? could you give me more details?


Remove Sliver at the Top of the Tab

There is a line under each tab in Jupyter Lab. It's somewhat hard to see...

Talked with the designers here at Cal Poly and all think we should remove the sliver of whitespace above the actual widget in each tab.

Individual widgets can add that space or more if needed.
More difficult to remove on individual basis.
Simplifies the design and works well with @SylvainCorlay proposed changes

That little line looks like it might be due to a drop shadow on the tab.
@ellisonbg which whitespace are you talking about?

I'm all for this change, except for the fact that it will make some of the designs look a little bit too cluttered up towards the top.

In the Notebook, the Code dropdown would be flush up against the tab bar and that would look 💀
Maybe there needs to be some sort of padding up towards the top, but completely removing the sliver might be a little excessive.

This was done in master...


Remove explicit port binding in Azurite container

Fixes #875.
Switched from explicit port binding to automatic assignment to avoid port conflicts.

One test failing:
FAIL packages/modules/azurite/src/azurite-container.test.ts (38.5 s)
  Azurite
    ✓ should upload and download blob with default credentials (10494 ms)
    ✓ should add to queue with default credentials (1322 ms)
    ✓ should add to table with default credentials (1306 ms)
    ✓ should be able to specify accountName and accountKey (1356 ms)
    ✕ should be able to specify custom ports (944 ms)
    ✕ should be able to use in-memory persistence (18332 ms)

  ● Azurite › should be able to specify custom ports

    expect(received).toBe(expected) // Object.is equality

    Expected: 13000
    Received: 32783

      125 |       .start();
      126 |
    > 127 |     expect(container.getBlobPort()).toBe(blobPort);
          |                                     ^
      128 |     expect(container.getQueuePort()).toBe(queuePort);
      129 |     expect(container.getTablePort()).toBe(tablePort);
      130 |

      at Object.<anonymous> (src/azurite-container.test.ts:127:37)

  ● Azurite › should be able to use in-memory persistence

    RestError: connect ECONNREFUSED ::1:32786

      at ClientRequest.<anonymous> (../../../node_modules/@azure/core-rest-pipeline/src/nodeHttpClient.ts:223:11)

Fixed test 'Azurite › should be able to specify custom ports'
In the test 'Azurite › should be able to use in-memory persistence', container.refresh() now binds a new ports. So, I modified the test to create an azurite client from a new connection string including the new ports.


Improved missing assertion error

This pull request introduces errorMode overriding by setting the errorMode on
an error.
Adds colors to the missing assertion error.
Add a newline to the missing assertion error as it is long.
Support nesting the missing assertion errors into satisfy diffs.

Coverage increased (+0.03%) when pulling fd72dd55cad61837b69d54378ed611152175bae5 on feature/improved-missing-assertion-error into 377150907c765dab09b6bc065d987592307f8f0a on master.


feat(grpc-web): make public some methods to enable grpc-web client proxying

Motivation
I want to create a middleware grpc service that can listen to regular grpc calls, and forward them to another service as grpc-web calls. In order to do this fully generically, there needs to be made public some internals of tonic that are normally called via the Grpc service that the generated service code uses.

Solution
Publish the minimal set of symbols that are required

If there is interest, I can create a new example in the examples dir to demonstrate grpc-web proxying. I've only tested unary calls locally so far.

relates to #31 but doesn't necessarily close it

Marked as ready for review, but note it is not ready for merge as it needs docs on the newly public interfaces and possible an example of use. Just want to make sure the concept is sound before I put further effort in.

I think these changes are okay (once CI passes).

@tottoto thanks for the review, I've fixed up the CI with some docs, and added a new example demonstrating a super basic proxy that just passes a request on. Of course my real world proxy does more things like grpc-web translation but I wanted to keep it smallish.

I don't think we want to add yet another example here. Would be good to get the documentation additions squashed into the initial commit, though.

@djc I understand the resistance to the proliferation of too many examples though since this one touches these newly public api do you reckon I'd be better of reformulating the example as an integration test?

For now, I've dropped the example from this PR entirely so we can get this in and continue discussion in another PR if that's a preferred option?

I think the remaining CI failure is fixed by #1906

@tottoto any chance you could have another look at this PR? Thanks!


ios 14.2 iphone 8 can't read tags

Hello,
After user initialises scan and cancels it, SessionClosed event is usually not received (sometimes it is received, I would say it works fine about 30% of the time, maybe lower) for iOS 14.2 with iPhone 8 and so user cannot read another nfc tag, also SessionClosed event sometimes is not received after successfully scanning a tag. But it works fine on iOS 14.2 iPhone XR.
Tried on 2.2.0 library version and on 1.2.6.
Haven't tried on any other iPhone.
Maybe someone has similar issue?
Update: looks like this can also happen on iPhone XR but it is much more rare. From debugging it seems that if user calls registerTagEvent right after previous session closed then new session will be initiated but NFC scanner will not show up on screen and so user can't scan tag or cancel scanning but can't figure out if there's some delay I could put to scanning next tag, calling registerTagEvent after a second or two of when session was closed still sometimes reproduces this issue. Calling start (from what I can see it just sets session to nil) method or reopening the app solves the issue. But, from example code, calling start every time you wan't to scan a tag look like the right approach.
Thanks in advance

Update: looks like this can also happen on iPhone XR but it is much more rare. From debugging it seems that if user calls registerTagEvent right after previous session closed then new session will be initiated but NFC scanner will not show up on screen and so user can't scan tag or cancel scanning. You have to close and reopen app.

i am experiencing that same issue!


Fix grammar in message_success_live and pending

Just a quick grammar fix we noticed when using the service.
Thanks so much for all you do!

Awesome!  Thanks @BrianNewsom !


Update go mod

Codecov Report

Merging #217 into master will not change coverage by %.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #217   +/-   ##
=========================================
  Coverage     96.73%   96.73%
  Complexity       21       21
=========================================
  Files             3        3
  Lines           153      153
  Branches          3        3
=========================================
  Hits            148      148
  Misses            4        4
  Partials          1        1

Flag
Coverage Δ
Complexity Δ

#go
96.90% <ø> (ø)
0.00 <ø> (ø)

#java
96.42% <ø> (ø)
21.00 <ø> (ø)

Continue to review full report at Codecov.

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


Update scala-collection-compat to 2.2.0

Updates org.scala-lang.modules:scala-collection-compat from 2.1.6 to 2.2.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang.modules", artifactId = "scala-collection-compat" } ]

labels: library-update, semver-minor

Codecov Report

Merging #863 into develop will decrease coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #863      +/-   ##
===========================================
- Coverage    89.34%   89.29%   -0.05%
===========================================
  Files          117      117
  Lines         9326     9326
  Branches       365      365
===========================================
- Hits          8332     8328       -4
- Misses         994      998       +4

Impacted Files
Coverage Δ

...n/scala/com/twitter/algebird/SuccessibleLaws.scala
76.92% <0.00%> (-15.39%)
:arrow_down:

...main/scala/com/twitter/algebird/monad/Reader.scala
52.94% <0.00%> (-5.89%)
:arrow_down:

...in/scala/com/twitter/algebird/scalacheck/Gen.scala
95.34% <0.00%> (-4.66%)
:arrow_down:

...src/main/scala/com/twitter/algebird/Interval.scala
83.47% <0.00%> (ø)

.../main/scala/com/twitter/algebird/Applicative.scala
54.83% <0.00%> (ø)

.../main/scala/com/twitter/algebird/BloomFilter.scala
94.69% <0.00%> (+0.44%)
:arrow_up:

Continue to review full report at Codecov.

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


Discussion roadmap v1.0

I'm creating milestone v1.0. https://github.com/pablodav/kubernetes-for-windows/milestone/1
I have finally got merged into kubespray the required support for this project:
https://github.com/kubernetes-incubator/kubespray/pull/3200#issuecomment-418087989
These are very good news now, as we can start focusing more on windows requirements.
Also implemented upgrade to have support for kubernetes v1.11.2 (with kubespray + updates in this project).
Let's have this thread for discussion.
ping @ptylenda

I still need to familiarise myself with both ansible and kubespray, but in my eyes a 1.0 would be a version that can reliably build-up a cluster containing Windows nodes in a fixed, but functional, configuration. Flexibility falling in the post 1.0 era.

Looks like we have some support official support for CNI on windows finally, let's hope it will work without any workarounds: https://github.com/containernetworking/plugins/pull/193
BTW the biggest issue to me with kubernetes for windows is inherent problems with HNS networking and NAT vs internal cluster communication problems. I expect that after last 4-5 months, fixes have been released to the latest version of insider builds of Windows and together with new CNI we can get a good setup for migrating existing windows apps/services to k8s. We should also fully support vxlan and host-gw plugins, as far as I remember, I have managed to get host-gw working only, whereas vxlan had some bugs in CNI plugins. I expect that this is also fixed with the above PR.
Apart from that for 1.0 milestone, it may be a good idea to adjust windows services management, in k8s 1.10 there was a pull request for native services support (without nssm + ansible of course) for kubelet: https://github.com/kubernetes/kubernetes/pull/60144

Great, good news.
I agree with the native services support.

Awesome, good to see this! 🎉
@ptylenda both internal cluster communication via pods or services, as well as outbound NAT works today simultaneously. But if you are using VM's you need to enable Mac spoofing for your VM network adapter, else cluster communication will not work.
If outbound communication isn't working I would check the ExceptionList l2bridge.conf or cni.conf which specifies an OutboundNAT Exception list where we don't want NAT'ing to occur. Usually something is wrong there when people report outbound connectivity issues.
Also, please do not use ping <IP> for anything that requires NAT to demonstrate connectivity because there are no ICMP rules programmed in VFP (Windows equivalent of iptables). Please use TCP/UDP protocol, or curl <IP> equivalent.

There is a basic band-aid guide here to deploy using flannel (host-gw) mode, but I'm hoping to update official docs as soon as I can.

Kubernetes SIG-Windows group is doing lot of work for 1.14:
https://github.com/orgs/kubernetes/projects/8
https://github.com/kubernetes/enhancements/issues/116
Looks like it would be in better shape.

Lot of things have been improved with k8s 1.14 and windows 2019 ltsc.
https://kubernetes.io/docs/setup/windows/#supported-functionality
Looks like it should be the target version to support.


Add em helper

Adds the em helper. Please check if this works the way you'd expect it to!
I had to add a eslint-disable for the parameters reassignment, what do you think about disabling that rule?
Also stripUnit might return a string since it returns the original string if it's not a number, so flow complains if I just do pxval / base because those might be strings. Unsure what we want to do here, so I've just disabled flow for that line. Any ideas? /cc @relekang

Current coverage is 100% (diff: 100%)

Merging #34 into master will not change coverage

@@           master   #34   diff @@
===================================
  Files           5     6     +1
  Lines           9    14     +5
  Methods         0     0
  Messages        0     0
  Branches        0     0
===================================
+ Hits            9    14     +5
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update 664d152...cb8b349

Unsure what we want to do here, so I've just disabled flow for that line. Any ideas?

What about this?
return `${parseInt(pxval, 10) / parseInt(base, 10)}em`

Well but stripUnit already does that. The case of a string being there would only ever happen when base or pxval are invalid.

Ah okay, should have checked the source of stripUnit.
I think the flow team is working on improving the applications of typeof checks. We can probably add the suppresser for now an look more into what we can do about it. However, with the suppresser I think we should type the return value of the function.
Using a function and type it with /* : %checks */ like we did for isTag in styled-components might work.

Using a function and type it with /* : %checks */ like we did for isTag in styled-components might work.

Unsure how that works, but you should be able to push to this branch – would you mind trying that? Thanks!

Sure, I do not have time today, but will do it tomorrow ✌

Fixed by throwing an error from em(), what do you think @bhough? Is this reasonable/expected behaviour?

Fixed by throwing an error from em(), what do you think @bhough? Is this reasonable/expected behaviour?

I think so, once we implement #4 we will be doing a lot this anyway.

I had to add a eslint-disable for the parameters reassignment, what do you think about disabling that rule?

Maybe better to take a functional approach and reassign it to a new value newPxval = stripUnit(pxval).

Resolved all the issues, please review again!

@mxstbr Two small comments, otherwise looking good. The endsWith helper will be nice for some better error handling on existing mixins as well.

Added @flow to endsWith, the assignment actually needs to be there in case numbers and not strings are passed! Ready to go I think?

Will need to somehow exclude internalHelpers from the JSDoc rules. Otherwise, good to go.

Just need to mark it as @private, one sec!


Show "deploy to AZ" option only in AZ capable region (Portal UI)

ADO tracking:
https://unifiedactiontracker.visualstudio.com/Solution Engineering/_workitems/edit/117187

Feature/Enhancement moved to ADO board for tracking


Error in boost library when compiling an application

Hello everyone.
I am trying to compile an external cpp project that uses boost (linked and built with CMake).
However the following error is thrown while compiling the project.

I am on Debian testing (trixie) and the boost library is installed via apt install libboost1.83-all-dev.
In my laptop I have dnf as a package manager, and I installed with dnf install boost-devel (it installs 1.81.0 version) and everything compiled (and ran) fine.
Am I missing something while installing the library?
Thanks in advance.

<algorithm> is a standard library header file, not part of boost.  I suspect that something in your setup is incorrect.


Possible to include all minfi's cell type references in the meffil.estimate.cell.counts.from.betas function?

The current function only estimates cell types in blood/saliva. Could you please also include the brain (DLPFC) cell type reference (from minfi) in this function?

Hi Lei-Guo,
Sorry about the wait.  I haven't been monitoring this closely enough.  I've recently added this, it is named "guintivano dlpfc".
Matt

Hi Matt,
to my understanding, this is one of the few, if not the only, function in R that can estimate cell counts for saliva samples specifically (besides GLINT perhaps?). I have a study in which I want to estimate cell counts from saliva samples. I noticed that in the abovementioned function there is the reference called "saliva gse48472".
I assume this should not be used for both saliva and buccal cells, but only saliva, correct?
Could you then give me more information on that cell-type reference, and whether there is a reference study/publication that report it?
I would appreciate it very much, because I am planing to use your function in my pipeline.
*Maybe one suggestion would be to add this information in the documentation of the package.

Hi Samuel,
This particular cell count reference is obtained by combining a white blood cell type reference (GEO dataset: GSE35069https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE35069) with a buccal cell type reference (the buccal DNA methylation profiles from GEO dataset GSE48472https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE48472).  It assumes that the cell content of saliva is a mix of white blood cells and buccal epithelial cells.
You could use this for either buccal samples or saliva samples.
Best,
Matt

From: Samuel Carleial<EMAIL_ADDRESS>Sent: 21 October 2020 8:37 AM
To: perishky/meffil<EMAIL_ADDRESS>Cc: Matthew Suderman<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [perishky/meffil] Possible to include all minfi's cell type references in the meffil.estimate.cell.counts.from.betas function? (#24)
Hi Matt,
to my understanding, this is one of the few, if not the only, function in R that can estimate cell counts for saliva samples specifically (besides GLINT perhaps?). I have a study in which I want to estimate cell counts from saliva samples. I noticed that in the abovementioned function there is the reference called "saliva gse48472".
I assume this should not be used for both saliva and buccal cells, but only saliva, correct?
Could you then give me more information on that cell-type reference, and whether there is a reference study/publication that report it?
I would appreciate it very much, because I am planing to use your function in my pipeline.
*Maybe one suggestion would be to add this information in the documentation of the package.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/perishky/meffil/issues/24#issuecomment-713373813, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACSRUUNJICU2L6H7AO6OAITSL2FURANCNFSM4LQP6XKA.

Hi Matt,
I found that out also inside your code. Thank you for the feedback!


Cannot login with new Keybase app (1.0.16-20160615195851+9200593)

I've put the keybase app in my Applications folder on OSX
When I try to login with the GUI, I am asked to enter username/email and passphrase. After the passphrase is entered, I get:
"There was an error provisioning
Unknown error: Error: GPG is unavailable on this device"
my log id: 2e5e257b6369f5b5fdbe5b1c

I resolved this by doing keybase login at the command line (which also created a paperkey). I am now logged into the GUI. I feel the GUI login could have mentioned this.
Thanks for the awesome and incredibly competent effort at making keybase!

As a heads up i bumped into this error too and didn't know what to do (except search for other people with the same problem) until i landed on this ticket!
I also solved my problem by logging in via the keybase command.


Expected response code 354 but got code "554", with message "554 5.5.1 Error: no valid recipients

Q
A

Bug report?
yes/no

Feature request?
yes/no

RFC?
yes/no

How used?
Standalone/Symfony/3party

Swiftmailer version
x.y.z

PHP version
x.y.z

Observed behaviour

Expected behaviour

Example


please bring back gamemode.ps1 pls

https://github.com/djdallmann/GamingPCSetup/blob/master/Scripts/GameMode.ps1

It’s still there, reorganized things a while back.
https://github.com/djdallmann/GamingPCSetup/blob/master/CONTENT/SCRIPTS/GameMode.ps1


conditions

please if can ,add what all conditions can be added and their commands. thanks

It's only "Join channel" for now
On Tue, 29 Aug 2023 at 16:00, Nandinigarg09 @.***>
wrote:

please if can ,add what all conditions can be added and their commands.
thanks
—
Reply to this email directly, view it on GitHub
https://github.com/y9san9/prizebot/issues/121, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALGBTRUORW6YVO64M4G6R4LXXXRWJANCNFSM6AAAAAA4C5MXWQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi ,
Thank you for your reply,
I hope to see many more conditions to be added .
Like we do gaming giveaways,so something maybe in that direction.
Example to invite people to the channel
Thanks
On Thu, Aug 31, 2023, 2:42 PM Alex Sokol @.***> wrote:

It's only "Join channel" for now
On Tue, 29 Aug 2023 at 16:00, Nandinigarg09 @.***>
wrote:

please if can ,add what all conditions can be added and their commands.
thanks
—
Reply to this email directly, view it on GitHub
https://github.com/y9san9/prizebot/issues/121, or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ALGBTRUORW6YVO64M4G6R4LXXXRWJANCNFSM6AAAAAA4C5MXWQ>

.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
https://github.com/y9san9/prizebot/issues/121#issuecomment-1700662602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCG5Z3KUBBYG5SUNOSB3UA3XYBIRJANCNFSM6AAAAAA4C5MXWQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Release 0.2.115 to crates.io.

Needed by https://github.com/rust-lang/rust/pull/93351.
Should have included this in my prior PR but hadn't finished reading CONTRIBUTING.md. Sorry for the extra traffic!

r? @Amanieu
(rust-highfive has picked a reviewer for you, use r? to override)

:pushpin: Commit fffd9cf6100e1a8d19749926aa75c4a1a550fa8b has been approved by Amanieu

:hourglass: Testing commit fffd9cf6100e1a8d19749926aa75c4a1a550fa8b with merge 1068fee1011e08cd4a3bcf1c3e54af3f8339c372...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing 1068fee1011e08cd4a3bcf1c3e54af3f8339c372 to master...


Runtime-dependency on cabal executable?

I got this:
Ensuring cabal version is >= 2 ...
stack2nix: ERROR: cabal version must be 2 or higher. Current version: <IP_ADDRESS>
CallStack (from HasCallStack):
  error, called at src/Stack2nix/Util.hs:47:49 in stack2nix-<IP_ADDRESS>-3EqQ1tT1vMJGpAYSWfmhUQ:Stack2nix.Util

I see it calls cabal --version. Why is that?
stack2nix already link in the Cabal library, so couldn't it use only functionality from that? Then it wouldn't care about whatever cabal is in path (or even require it to be installed).

Another question: For now, how can I get exactly a version of the cabal executable that's known to work with stack2nix? Can I obtain it as part of stack2nix's nix-shell environment?

cabal update is still ran to make sure hackage db is up to date. It could be made optional.
iirc stack2nix did provision itself a cabal from nixpkgs, are you using master branch?

@domenkozar Yeah I'm in 9070f9173ae32f0be6f7830c41c8cfb8e780fdbf. In nix-shell --pure default.nix there's no cabal in PATH. Am I looking in the wrong spot?

Relevant #102


feat: replacing concrete client keeper struct with an interface

Description
This PR replaces the concrete ClientKeeper struct with an interface. This allows IBC-enabled applications to add extra functionalities atop the client keeper (without forking IBC-Go), including

adding hooks to these keepers, so that other modules can learn internal states of IBC
defining and emitting new events upon certain state changes in the IBC module
implementing new queries and messages for these internal keepers

closes: #2880

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Thanks for this contribution, @SebastianElvis! We will discuss and review in the coming weeks.
Do you already have a concrete use case to use this? Do you have any urgency to have this released soon?

Codecov Report

Merging #2967 (66199e4) into main (a66bc14) will decrease coverage by 0.03%.
The diff coverage is 38.46%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2967      +/-   ##
==========================================
- Coverage   78.55%   78.52%   -0.04%
==========================================
  Files         178      178
  Lines       12271    12278       +7
==========================================
+ Hits         9640     9641       +1
- Misses       2206     2211       +5
- Partials      425      426       +1

Impacted Files
Coverage Δ

modules/core/keeper/keeper.go
91.11% <ø> (ø)

modules/core/keeper/migrations.go
0.00% <0.00%> (ø)

modules/core/02-client/genesis.go
16.66% <50.00%> (ø)

modules/core/module.go
53.84% <50.00%> (-0.83%)
:arrow_down:

modules/core/02-client/abci.go
100.00% <100.00%> (ø)

modules/core/02-client/proposal_handler.go
77.77% <100.00%> (ø)

Thanks for the response!

Do you already have a concrete use case to use this?

Yep, we indeed have a concrete use case -- adding hooks over ClientKeeper for checkpointing light client headers.
Our project Babylon aims at building a blockchain Babylon that checkpoints other PoS chains to Bitcoin. The checkpointing process from PoS chains to Babylon leverages the IBC light client, where Babylon receives PoS chain's headers via IBC. In order to do the checkpointing, Babylon has to use hooks to get notification at the application layer upon receiving headers from IBC.
At the moment, we are maintaining a fork of IBC-Go that implements a hook AfterHeaderWithValidCommit. The hook is invoked upon a header with a valid quorum certificate from IBC. The most code of Babylon is still WIP and we hope to open-source everything as soon as possible.

Do you have any urgency to have this released soon?

Yeah we definitely hope to have this feature in the official IBC-Go implementation. Nevertheless, we respect your priorities. Before having this feature in IBC-Go we can still use our fork :) Thanks for asking.

Thanks @colin-axner for the feedback, which is really helpful! I have rebased the PR to the latest main branch, and fixed the comments. Specifically, this PR

changes the signatures of NewMigrator, PruneExpiredConsensusStates, and SetUpgradeHandler
removes unnecessary type assertions given the updated function signatures
adds documentations for clientexported.ClientKeeper and integration

Please feel free to have a look again.

Hi @SebastianElvis
Thanks for all the work you've been doing here, looking at the code, I am a little concerned about the size of the interface that ends up being required here, and a lot of these interface functions are actually implementation details (un/marshalling functions, client id generation etc. )
I was investigating an alternative approach which would allow custom logic to be executed at different client events (creation/upgrading/updating) through the use of hooks. I believe this should be enough to enable any sort of custom logic that is required while also making sure that the client keeper logic is guaranteed to execute as normal.
Please let me know what you think of this approach and if it is enough to implement the logic you want to add.
cc @colin-axner

Hi @chatton , thanks for the feedback!

Thanks for all the work you've been doing here, looking at the code, I am a little concerned about the size of the interface that ends up being required here, and a lot of these interface functions are actually implementation details (un/marshalling functions, client id generation etc. )

Yep I agree with that. It's indeed not good to have an interface that includes a number of functions that concern implementation details.

I was investigating an alternative approach which would allow custom logic to be executed at different client events (creation/upgrading/updating) through the use of hooks. I believe this should be enough to enable any sort of custom logic that is required while also making sure that the client keeper logic is guaranteed to execute as normal.

Thanks for your investigation and work. I believe adding relevant hooks directly to the client keeper suffices for our use cases and is much cleaner than the interface approach.
One thing is that our use case needs to distinguish between a header in the canonical chain and in the fork (i.e., has a valid quorum certificate but has non-monotonic timestamps or conflicting header). What we did is to provide the hook with a boolean value which indicates whether the header is canonical or fork (see here and here). This is difficult to be done in an external module subscribing to client keeper hooks since the external module does not have access to clientStates. Is it possible for you to implement something similar? Thanks!

Closing for now, since the use case can be accomplished with SDK post handlers.


issue

Challenge Use a CSS Class to Style an Element has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
 It should be:

 Cat Photo App

@beans1991 To references classes in CSS, you need a period before the class name, like .red-text. There's also a problem with your opening h2 tag.
Please visit the Help Room for issues like this, in future.


Python.Launcher.3.12 version 3.12.0

Resolve https://github.com/microsoft/winget-pkgs/issues/121195 .

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.5 schema?
[x] Have you tested your manifest in Windows Sandbox with Tools/SandboxTest.ps1 -Manifest <path>?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@wingetbot waivers Add Validation-Executable-Error

LGTM :shipit:

@wingetbot waivers Add Validation-Executable-Error

@wingetbot waivers Add Validation-Executable-Error


[Breaking Change Request] [io/http] Drop Content-Length:0 header from GET/HEAD requests

Summary
We propose to not to include Content-Length header in GET/HEAD http requests when its value is 0(when there is no body as part of http request).
Rationale
Presence of Content-Length:0 header runs against guidelines provided in RFC-7320 https://tools.ietf.org/html/rfc7230#section-3.3.2, which states that
A user agent SHOULD NOT send a
   Content-Length header field when the request message does not contain
   a payload body and the method semantics do not anticipate such a body.

The fact that dart:io HttpClientRequest code includes Content-Length:0 header in GET requests was recently found to be a culprit of inability for Dart http client code to talk to Google Cloud Run websocket services (see https://github.com/dart-lang/sdk/issues/45139). So this change will fix that problem.
See https://dart-review.googlesource.com/c/sdk/+/194881 for the actual change.

What about other methods that also don't have defined semantics for a payload, like DELETE?

@rspilker wrote
What about other methods that also don't have defined semantics for a payload, like DELETE?

Good question, thanks for pointing that out.
Per https://tools.ietf.org/html/rfc7231 It looks like DELETE and CONNECT in addition to GET and HEAD have similar language that "A payload within a ... request message has no defined semantics;
sending a payload body on a HEAD request might cause some existing
implementations to reject the request."
I believe we should extend proposed change to all four.

any updates on this @franklinyow ?

Ping @vsmenon @matanlurey @Hixie for approval

Following the standards SGTM.

lgtm

Approved

Any updates?
Really would like to have this fixed so I could remove the massive workaround in my project.
Thanks!

If I read the information in the commit correctly, the change is included in the dev releases since 2.14.0-181.0.dev

Fixed in https://github.com/dart-lang/sdk/commit/6c254fab89adbeebfb616cdec497260db4cb7cf7


Ability to pass in custom error message?

Environment

Tech
Version

material-ui-pickers
1.0.0-rc.12

material-ui
1.4.2

React
16.4.2

Browser
All

Platform
All

Peer library
moment

Is there a way to pass in a custom error message into these pickers? e.g. let's say I create a valid date/time with DateTimePicker, then submit that to the server, but the server decides there's something wrong with the date (e.g. it's before/after another date that the server has, but the client doesn't). I'd like to be able to pass in the error message that the server sends back, but there doesn't seem to be a way to do that. Does that make sense? Am I missing something?

Hi,
DateTimePicker uses materia-ui TextField under the hood.
So you're able to do something like:
<DateTimePicker
  // ...
  error
  helperText="Your error message"
/>

@cherniavskii thanks for the reply! Yes, that works, but only partially. Or, at least, there's another piece I can't figure out. The pickers often set their own internal error messages--for example if a user types in an invalid date, the components immediately display Invalid Date Format. What I'd like to do is say something like "if I have an external error message, display that; otherwise, display whatever error message is generated by the picker". I don't see a way to do that. e.g. if I do this:
      <DateTimePicker
        ...
        error={errorText && errorText.length > 0}
        helperText={(errorText && errorText.length > 0) ? errorText : null}
        ...
      />

...then the passed-in helperText value will always override the internally-generated message.
I think the only way to handle this right now is to set the component props outside the component itself, and then append a helperText prop if the parent component has an error value, like this:
    const pickerProps = {
       value: dateValue
      // other props...
    }

    if (errorText && errorText.length > 0) {
      pickerProps.helperText = errorText
    }

    return (
      <DateTimePicker
        {...pickerProps}
      />
    )

Maybe that's the "best" way to handle this condition, but it seems like it might be more elegant for the picker components to somehow allow for this.

Sorry. You're right when you say that "passing helperText always overrides internal error message". What I'm saying is that it might be nice if there were a way for the internal error message to show, if the passed-in value of helperText is null or something like that. Here's your sandbox, modified with helperText={null}:
https://codesandbox.io/s/rjw3qk7k3p
In that example, if you type gibberish into the date/time field, you don't see the internal error message, even though the passed-in value of helperText is null. Maybe that's the right way to design the API for these components, but it seems like it would be nice for there to be certain conditions under which the internal error message overrides the passed-in value (e.g. for null and undefined). Does that make sense?

Hey @bmueller-sykes!
I found a solution to your problem, you have to conditionally add the error and helperText properties to your react component, you can do this in the following way:
         <DatePicker
            value={selectedDate}
            onChange={this.handleDateChange}
            keyboard
            {...(hasError ? { error: true } : {})}
            {...(hasError ? { helperText: "Custom error message" } : {})}
          />

Where the variable "hasError" would be controlled by your external validation logic.
I modified your sandbox in:
https://codesandbox.io/s/wy4qxkqwj5

@bmueller-sykes You can use DateValidationProps and pass to component
<DatePicker
            {...props}
            minDateMessage="Date should not be in the past"
          />


De-activating series in stacked area chart does not work

When de-activating a series in a stacked are chart, the areas are not 're-stacked' as it were.
The result is that the series that are stacked on the deactivated series are still rendered as if it were active.
Example:

Series 1: [10 20 30]
Series 2: [10 20 10]
Show two areas:
One from [0 0 0] to [10 20 30]
One from [10 20 30] to [20 40 40]

When deactivating Series 1 it should render as

One serie from [0 0 0] to [10 20 10]

Instead it renderes like:

One serie from [0 0 0] to [20 40 40]

A picture says more than a thousand words, so I included two.

Hi Jeroen,
Thank you for reporting this issue. We will look into this.
Cheers, Andries

Hi @jeroen-huizer-conclusion, this is fixed now. Please update to the latest version and let me know if the fix is satisfactory.

Thanks guys!


Manifest v3 compatibility

Changes:

Host permissions have moved to host_permissions
The *://*/* permission was moved from optional_permissions to host_permissions

https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#host-permissions
I'll fix this as part of

https://github.com/pixiebrix/pixiebrix-extension/issues/287

Optional permissions are still not available/finalized in MV3, so this module can't support them yet.
https://groups.google.com/a/chromium.org/g/chromium-extensions/c/E-VTpwtSYxM

It does not support host_permissions yet

Fixed


DO NOT MERGE wip building out routes

Description
This is an ongoing branch where I'm (slowly) filling in the routes and finding my feet rust-wise. There are many issues here, feel free to fix or comment, but also know that I'll do a pass to clean up before seeking more in-depth feedback. 💜

Looking great so far! The flow to sign up for a developer account too 👍 Should be quite easy to enable app accounts too right? Pass in 'app id' instead of email + token and then check app id instead of token.

I haven't gotten quite that far, but yes! I think the approach overall should make it easier to add any sort of verification, and we can still support "Create an account" -> "Verify email" flows by just inverting the process and having the client cache the account creation data.

I am a little confused about the 'code hash' though. Why do you think we need that? Is it because the client will compute the hash as well? Also the account creation handler doesn't actually check for the code yet does it?

Strictly speaking it's not necessary, but just a little added safety. If we store the code directly, if someone were to get access to read our database, they could theoretically create accounts that looked verified but weren't actually. By hashing the code and using the did/ucan as requested, we remove virtually all doubt that the person who controls the email account has the code. The attack points become limited to mailgun and the user's email provider.


error on loading data in NeDB

I am trying to load bulk records (about 200K) into NedB. I get the following error
/path/to/node_modules/nedb/lib/persistence.js:195
toPersist += self.afterSerialization(model.serialize(doc)) + '\n';

RangeError: Invalid string length

Although NeDB does do its updates in append mode, it also does a full datafile rewrite at the end of the initial loading process and during every compaction operation.  If your total record size, when represented as a string, exceeds 256MB, then it will fail as Node.js does not support that large of a string.
See PR #463 for one proposed change that might fix this for you.
I've been working on resolving this in my fork, NestDB, (see https://github.com/JamesMGreene/nestdb/issues/6) but my work is temporarily stalled out due to lack of free time and a temporary deprioritization of my related at-work project.


Edge Hub's storage directory is persisted on the host filesystem - Error

Hi,
I have followed the instructions on
https://docs.microsoft.com/en-us/azure/iot-edge/quickstart-linux?view=iotedge-2020-11#deploy-the-iot-edge-device
...but the edgeHub module is not started on the newly created edge device VM:
sudo iotedge list
NAME             STATUS           DESCRIPTION      CONFIG
edgeAgent        running          Up 2 minutes     mcr.microsoft.com/azureiotedge-agent:1.2

Running the self diagnosis shows:
sudo iotedge check --verbose ...gives the following error:
× production readiness: Edge Hub's storage directory is persisted on the host filesystem - Error
    Could not check current state of edgeHub container
        caused by: docker returned exit code: 1, stderr = Error: No such object: edgeHub

The connected IotHub reports the following:

Thank you and best regards, Robert

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

ID: e2289383-6ce2-a036-c710-7d1fad6e1700
Version Independent ID: 3b902941-0876-17c3-3f0b-a4b7f7770531
Content: Quickstart create an Azure IoT Edge device on Linux
Content Source: articles/iot-edge/quickstart-linux.md
Service: iot-edge
GitHub Login: @PatAltimore
Microsoft Alias: patricka

Never mind, I found that the edgeHub module is only started once the first module is deployed, see here:
this https://docs.microsoft.com/en-us/answers/questions/416063/getting-error-34configuration-has-correct-uris-for.html
I could confirm this.


New log submissions process and tooling

New log summary tooling links and instructions.

Thanks @supermario!  I ran B2 & B6 and retrieved logs which are 1.9Gb each, and removed VM because I was running different VPS for different challenges. Now I saw that these log files was not retrieved fully and it shows that I was running for 5 days only, even I was running for full 7 calendar days. Now it somehow I have a snapshot of my B2 challenge server and retrieved with your new tool and it went very good has no big weight and shows that my B2 was running from 16 till 25 which is good. But I have a question what to do with B6, I only have this 1.9Gb log and syslog from server and I don't have a snapshot to retrieve log with new tool...