Option to Expect Specific Struct Name Upon Deserialization

I think it would be helpful to be able to enforce that a specific struct name is present when deserializing a struct. I mainly want to enforce this as part of style in my game's assets.

Thank you for the suggestion @SylvKT! At the moment, RON allows a struct to either be unnamed or to have the same name that serde specifies. Do you want an extension to forbid the former, i.e. that structs must always mention their name?

Thank you for the suggestion @SylvKT! At the moment, RON allows a struct to either be unnamed or to have the same name that serde specifies. Do you want an extension to forbid the former, i.e. that structs must always mention their name?

Yes, I'm looking for a way to force the struct in RON to be both named and match the name provided by serde.

@SylvKT Ok, thanks for the clarification! That shouldn’t be too difficult to add, my idea would be to add an extension, e.g. explicit_struct_names, and to check for it inside the struct parsing code. At the moment, we allow checking for the struct name to fail without modifying the parser state so that we can continue checking without a struct name. Now, if the struct name isn’t there, we would emit an error here.
At the moment, I’m unable to code it up myself for personal reasons but hopefully my explanation might be sufficient for you to submit a PR? I’d be happy to review it and to help you land it.


Ampersands in a blog summary cause invalid atom

Hey,
If I put an ampersand in the leading paragraph of a blog post, it becomes part of the  tag which causes the W3 validator to fail with this message:
summary should not contain HTML unless declared in the type attribute:
&

Here's a commit which demonstrates "fixing" a blog post by removing the ampersands:
https://github.com/paulfurley/paulfurley.github.io/commit/7bbc20754353b0277fdec7c6193516195fa06f22
Cheers!

This is odd; I would expect xml_escape to take care of this.

Oh, I get it.
Here is the rule we are breaking

Here is what the plugin was outputting:

    Public-key or “asymmetric” crypto is a cunning piece of maths (which I happily don’t
    understand) that’s at the heart of GPG. The incredible thing it allows is for us to
    communicate securely (signing &amp; encryption) without having agreed a secret
    in advance. This turns out to be a big deal.

Notice the &amp;
The feed validator claims we should be escaping this as & Also, because this is text rather than HTML, there is no need to double escape the ampersand. If this were HTML, we would escape it twice, once for the XML feed, and a second time for the HTML. But it is text, so we need to replace &amp; with &, I guess.

I noticed ampersands in post titles show up as & instead of & not sure if this is related or not.

I noticed ampersands in post titles show up as &amp; Running the feed through I get the following error: title should not contain HTML unless declared in the type attribute: & and the title's show up as:
<title>Title with an ampersand &amp; more text follows</title>

Just noticed this from https://validator.w3.org/feed/docs/warning/ContainsHTML.html:

Encoding of the characters "&" and "<" are especially problematic in places like RSS 2.0 titles.  For the widest interop, the RSS Profile recommends the use of the hexadecimal character reference "&" to represent "&" and "<" to represent "<".

Since this problem is showing up in the titles as well, perhaps using & is the correct solution.

I am still bothered by this. I haven't had time lately, but I still intend to figure out a better way to handle this.

Why is the plugin double escaping the ampersands in the first place. Since it's a text field it should pass through the character without escaping. Is there another filter touching this output before render?

@xHN35RQ I think the big thing is that we can't ahve < or > showing up inside text fields. Perhaps we can just replace those two characters instead of trying to escape everything?

I think the big thing is that we can't ahve < or > showing up inside text fields. Perhaps we can just replace those two characters instead of trying to escape everything?

Correct, after some inspection it appears HTML is only valid within <description> tags. So the characters that need special handling are &, < and >.
From http://www.rssboard.org/rss-profile#data-types-characterdata:

The specification has lacked clarity regarding whether HTML is permitted in elements other than an item's description, leading to wide variance in how aggregators treat character data in other elements. This makes it especially difficult for a publisher to determine how to encode the characters "&" and "<", which must be encoded in XML.

In elements that contain plain text, the form of encoding that works in the widest number of aggregators is using the hexadecimal character reference & to represent "&" and < to represent "<".

A publisher should encode "&" and "<" in plain text using hexadecimal character references. When encoding the ">" character, a publisher should use the hexadecimal reference >.

See also: http://www.rssboard.org/rss-profile#element-channel-item-description
Since jekyll-feed uses the Atom  tag instead of the RSS <description> tag it would make sense to follow your original suggestion to use hexadecimal character encoding instead of HTML encoding to ensure operability with the widest range of aggregators and to ensure validation.
By the way, if you use xml_escape within <description> tags (as occurs in the site_template included with jekyll) the generated &amp; is expected so it poses no problem and the feed validates nicely.
Perhaps jekyll-feed should replace these characters with the hexadecimal replacements after the XML escape perhaps with a filter. Perhaps a regex should be used here?
def hex_escape(input)
  input.to_s.gsub('&amp;', '&').gsub('<', '<').gsub('>', '>')
end

However if the job of xml_escape is to correctly format text for use in XML documents it would seem this should be handled by the xml_escape filter and not by jekyll-feed. So I'm not sure what the correct solution is. Perhaps this is a Jekyll core problem?

However if the job of xml_escape is to XML escape a string for use it would seem this should be handled by the xml_escape filter and not by jekyll-feed.

If that is not what xml_escape is for, then I don't know what is. That said, the xml_escape filter is just a thin wrapper for Ruby's encode, which uses named entities. So I'm not sure where the problem needs to be fixed.

Perhaps jekyll-feed could use a filter such as the following.

Yeah, I think that's probably best.

This is an RSS specific issue. Only a few entities need to be hexadecimal for just a few specific RSS fields. So I wouldn't expect Ruby's encode to handle this specific RSS edge case. However while the description for Jekyll's xml_escape is rather generic Escape some text for use in XML. - in practice this filter is used primarily for RSS/Atom XML generation.
So either Jekyll could add RSS specific filtering to xml_escape OR keep the existing filter as a generic XML features, and add an RSS specific filter feed_escape.
Either way, I feel this is a Jekyll core issue, because this problem is resultant from xml_escape being used in RSS specific cases... and Jekyll should provide a fully working RSS-aware filter for users.

For what it is worth, the named entities are valid XML, and Atom is based on XML. The Atom spec says specifically in reference to "title":

Entities such as "&" and "<" represent their corresponding characters ("&" and "<", respectively), not markup.

I am beginning to think this is a case where the validator is wrong.
Is there a feed reader that chokes on these entities, or is it just validator.w3.org?

So while this thread was an interesting discussion of the differences between RSS and Atom feeds, it seems the answer lies back up in your comment here: https://github.com/jekyll/jekyll-feed/issues/98#issuecomment-187706302

we could add  and call it a day.

The validator is throwing the errors because  is a plain-text only field, and either requires hexadecimal encoding, or it requires a type= tag to denote what the content encoding is. This applies to both RSS and Atom feeds.
Check out the Atom spec here: https://validator.w3.org/feed/docs/atom.html#text - it states that <title>, , <content>, and <rights> default to plain-text, but can also take the type="html" tag:

If type="html", then this element contains entity escaped html.

<title type="html">
  AT&amp;T bought &lt;b&gt;by SBC&lt;/b&gt;!
</title>

This answers your question earlier:

I wonder on what other elements this might be an issue. Should we just add type="html" to anything that will allow it?

No, only apply it to those fields that the validator specifically highlights as invalid when containing anything but plain-text. And if you wanted to be super safe, only apply it to <title>, , <content>, and <rights>
So in summary, Jekyll, and jekyll-feed are escaping XML correctly, everything is working fine on that end... it's just the jekyll-feed template that needs some adjustment. I'm sorry I didn't notice this earlier.

Since I noticed that <title> was throwing the same error for me: https://github.com/jekyll/jekyll-feed/issues/98#issuecomment-204940744 - so apply type="html" to at least <title> and . It is already applied to <content>

The Atom spec also addresses the HTML issue here: https://tools.ietf.org/html/rfc4287#section-<IP_ADDRESS>

The validator is throwing the errors because  is a plain-text only field, and either requires hexadecimal encoding...

Why? According to whom? Not according to the Atom spec

<IP_ADDRESS>.  Text
Example atom:title with text content:

     Less: <

> ```
>
>   If the value is "text", the content of the Text construct MUST NOT contain child elements.  Such text is intended to be presented to humans in a readable fashion.  Thus, Atom Processors MAY collapse white space (including line breaks) and display the text using typographic techniques such as justification and proportional fonts.
Since it seems this is only a problem for validator.w3.org, I am going to close this for now as wont-fix. If a problem with a feed reader is discovered in the future, we can take another look.

The validator chokes because it is following the spec. So does Firefox and it chokes too. Whenever I preview a feed in Firefox that has been generated by jekyll-feed, I see the same encoding problems in the <title> and the <summary>
As per <IP_ADDRESS>, the title type defaults to text. As such it must not contain child elements. You can use hexadecimal in type text if you want to, and it seems to validate fine.
However since Jekyll is putting HTML into the <title> and <summary> you need to use the type html on those fields... see the very next section: https://tools.ietf.org/html/rfc4287#section-<IP_ADDRESS>

<IP_ADDRESS>.  HTML

Example atom:title with HTML content:

  Less: <em> < </em>

```

If the value of "type" is "html", the content of the Text construct
MUST NOT contain child elements and SHOULD be suitable for handling
as HTML [HTML].  Any markup within MUST be escaped; for example,
"
" as "
".  HTML markup within SHOULD be such that it could
validly appear directly within an HTML
 element, after
unescaping.  Atom Processors that display such content MAY use that
markup to aid in its display.

Please re-open as jekyll-feed should either set <title> and  tags as type="html" or should stop generate HTML in those tags, and only generate plain text in those tags.
I'm happy to push a PR if you want.

Sorry, the named entities thing got me distracted from the real issue. We are double escaping entities.
Using numbers instead of names does not fix the problem.

No problem. My apologies for my earlier comments that distracted from the real issue. I didn't fully understand the problem until just today.


FYI: API performance

Just an FYI. I'm sure various factors impact this, but I ran a script to encode many entries in a db, and the API supported about 4 calls per second. Web server is nginx running php 7.4, on ubuntu linux, on a fairly resource limited VM. At any rate, I won't ever need to "bulk encode" like this, but it was interesting to see that it could zip through 700-odd encode calls in test.

Cool! I haven't done any true performance evaluation, but Steganographr isn't doing anything overly taxing and should run pretty swiftly. But you're right, there are quite a few variables that can come into play for operations per second. Was your script was performing the encoding and then immediately INSERTing into your database? I could easily see the core API performing more than 4 conversions per second (likely many more) but database overhead play a large role in overall speed.
Salty, on the other hand, is doing quite a bit more heavy lifting with respect to cryptographic functions—so batch operations would be comparatively slower with it over Steganographr.

The script is running via a UI layer on top of the db and yes, inserting for each encode op, so, there's overhead there as well that I forgot to mention. If I ran the script purely from the CLI on localhost, I think it would be faster. And yes, anything crypto always uses lots of CPU and RAM.


Nuget update to 1.0.4

Description
Hi,
Do you have an ETA when you will push 1.0.4 to nuget?
Background
No response
Specification
No response

Maybe a cache problem?
https://www.nuget.org/packages/AngleSharp

Hi,
Thanks for your response but  i asked about AngleSharp.CSS not being the
alpha release: https://www.nuget.org/packages/AngleSharp.Css/1.0.0-alpha-99.
Maybe I posted my question to the wrong repository then?
On Thu, Aug 10, 2023 at 12:39 AM Wolfgang Kluge @.***>
wrote:

Maybe a cache problem?
https://www.nuget.org/packages/AngleSharp
[image: image]
https://user-images.githubusercontent.com/639482/259445986-6d961f55-a889-4c2b-b22b-8cca4a166682.png
—
Reply to this email directly, view it on GitHub
https://github.com/AngleSharp/AngleSharp/issues/1132#issuecomment-1671523428,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUJ2HOOVYTTXKTCA2OCRKDXUOOIVANCNFSM6AAAAAA3JDLGCI
.
You are receiving this because you authored the thread.Message ID:
@.***>


chef-client logging

need to set node['chef_client']['config']['log_level'] to something reasonable (probably
just higher than the DEBUG level).

we should be a the default INFO now with the upstream chef-client cookbook.


[Feature] Implementing GH actions (GHA) as method to run K3ai from within the repo

As an extension of #18, we should aim to develop a GHA that allows a user to operate directly from within its own repo.

I'm working on it, I found some flaws:

The PAT is always read through user input; there is no option of passing PAT through a flag.
I tried piping the PAT to k3ai up, but it didn't work.

Hence, I'm working on writing a fix, which adds a -p flag for the PAT token. It works locally for me, I'll open up a PR on your approval.
This would potentially work with GitHub Actions, with the usage of yes to bypass the prompt wait. Here's how it works locally
❯ yes | go run main.go up -p "<GITHUB_TOKEN>"
🎉🎉🎉 Welcome to K3ai 🎉🎉🎉
📢      Give us a second and we will start the process...
 ❌     Missing GitHub Authentication Token, please paste it here:
 ✔     GitHub Authentication Token: OK
 ❔     To avoid asking for the token everytime, are you ok if we save it as .env variable?
✔ Yes
 ✔     Proceeding with configuration,please wait...

 🚀     Loading K3ai configuration...  100% |████████████████████████████████████████|    s:0s]
 🚀     Creating database...           100% |████████████████████████████████████████|    s:0s]
 🚀     Retrieving plugin list...        2% |                                        |  [0s:2s]

Feel free to respond to this after the weekend. My intention is not to annoy you. 😊

So cool! Passing the PAT as a flag sound a good idea I was thinkin we may do a community session next week to talk about some of the ideas. And no worries I'm super happy you like to help on this project !!!

If you want me to add this feature, could I open up a PR today?

K3ai is for the people so yes anytime you like!!!

Update:
I have set up a minimal example of setting up a k3ai cluster using Github Actions. You can see it action here.
The current workflow doesn't use the binaries, as they don't have support for passing PAT tokens through the -p flag yet.

I like that my idea is o actually to read a confit in the repo to tell us what to install ( I.e. cluster X plus plug-in Y) so we may read the repo and excute the pipeline. Ideally grab the outcome and write it back in a folder in the repo.
So your GH is a great starting point !!! Amazing job

Yes, I know about the "extracting the config" part. This was just a proof of concept; I was excited to try it on Github Actions! 😋

And you did an amazing job... if we make this it will be awesome just think about be able to run a training job directly in GH actions !

Keeping this open as we still have to deal with a complete end-to-end workflow. (Artifact collection support is missing)


Introduce configuration for returning Date object as primitives

Sometimes, returning a Date as a long or String might be preferred to that of a rich object where available. While the user can do so by implementing their own deserializer, it would be nice/convenient to have this provided out of the box.

I'm not entirely sure if this is being considered or not, but it does seem that this is less of a static configuration if I'm understanding it correctly.
ES seems to allow you to write a Date value in a variety of formats. What I'm hoping for is that the interfaces between ES and processing frameworks like Hadoop and Spark will dynamically deserialize into the correct data type given the format it is stored in.
So if I have a mapping like:
"created_at": {
    "type": "date"
},
"updated_at": {
    "type": "date",
    "format": "yyyy-MM-dd"
}

and I index a long UTC millis value to created_at and a human readable date string to updated_at I would expect to get the same formats back during the deserialization process.

The issue has been addressed in master, the docs updated and the nightly builds published.
In short, by default, date objects are returned as rich objects (they vary depending on the library used). To get the fields as primitives (long or String depending on how they are stored), one should use es.mapping.date.rich field and configure it to false.

Closing the issue; if the problem persists please create a new one.


apple_music: Fix creation of dummy albums

Fix TypeError on creation of dummy albums (Introduced in https://github.com/music-assistant/server/pull/1463/)
@MarvinSchenkel See comment in https://github.com/music-assistant/hass-music-assistant/issues/2431

Awesome find. Thanks 🙏


A issue in React-Native

After i import babel-plugin-transform-decorators-legacy,i can't open my project any more.
when i run 'react-native run-ios',a error appeared:
error: bundling failed: TypeError: Property right of AssignmentExpression expected node to be of a type ["Expression"] but instead got null
in package.json, devDependencies is
"babel-plugin-transform-decorators-legacy": "^1.3.5",
"babel-plugin-transform-runtime": "^6.23.0",
"babel-preset-react-native-stage-0": "^1.0.1",
"babel-preset-stage-1": "^6.24.1",
did i miss something ?

It is hard to say without the rest of the error message. The stack trace will give more information, please include it.

@loganfsmyth Thanks.
I fixed this problem with upgrade babel to 7.0.0-beta.47.

@wsxiaoluob This plugin is only for Babel 6. See https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy#babel--7x


fix: Collection profile mobile filter missing styles

PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #9116

Did your issue had any of the "$" label on it?

[x] Fill up your DOT address: Payout

Screenshot 📸

[x] My fix has changed something on UI;

thanks!
pay 20 usd

😍 Perfect, I’ve sent the payout
💵 $20 @ 6.39 USD/DOT ~ 3.13 $DOT
🧗 16faLfsywwNATaEfbH2ah75dn6ZmctQWpMS5G4KFhbmj5hnD
🔗 0x201587ea5c611b8afe688586f9a3ec4d91cdbc62d53f090c7749d52f969add57
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Refine auto-tags feature to simplify ambiguous tag filtering cases

[ ] Rename current auto-tag name to fullname
[ ] Add a new auto-tag for name
[ ] Add unit tests
[ ] Update docs
[ ] Update built-in workloads
[ ] Update blogs if needed
[ ] Add a contextual warning for cases where a tag filter with name name is used.

Current State
Consider a user has a workload template like this:
blocks:
 yakshaver:
  ops:
   yakshaver-1:
    ...
   shornyak-1:
    ...

current auto-tags
NB automatically adds tags to this which are virtual and not user settable, equivalent to this:
blocks:
 yakshaver:
  ops:
   yakshaver-1:
    tags:
     block: yakshaver
     name: yakshaver--yakshaver-1
    ...
   shornyak-1:
    tags:
     block: yakshaver
     name: yakshaver--shornyak-1
    ...

Notice that the name 'yakshaver--yakshaver-1' is an expansion of the pattern <blockname>--<opname>. This makes the "name" tag globally unique within the document as a side-effect of unique block names and op names within a block.
However, we have found that this creates a confusing usage pattern for users who tag filter with regexes. Case in point:
The tag filter tags="name:yakshaver.*" matches all op templates. This is counter intuitive since the tag named name is strongly suggestive of the op name. When the blockname prefix matches an op name prefix, such patterns only create more confusion.
Alternative
An alternative to this is to simplify the usage of auto-tags, so that they simply contain the values present in the yaml structure. This means that faceted filtering of tag value would work as expected. It is also a simpler case for matching either or block and op template name, since you can combine them easily. In order to allow the previous matching behavior, another concatenated form could be provided under the tag name fullname, short for fully-qualified name.
new auto-tags
With these changes, the original workload template would be equivalent to this after being loaded:
blocks:
 yakshaver:
  ops:
   yakshaver-1:
    tags:
     block: yakshaver
     op: yakshaver-1
     fullname: yakshaver--yakshaver-1
    ...
   shornyak-1:
    tags:
     block: yakshaver
     op: shornyak-1
     fullname: yakshaver--shornyak-1
    ...

With this form, the ambiguity around how to match is removed for the most obvious tag names.
Matching all templates in a block
tags=block:yakshaver

Matching all templates with an op name pattern
tags=op:yakshaver.*

Matching all templates in a block with an op name pattern
tags=block:yakshaver,op:yakshaver.*

Compatibility
This is not backwards-compatible, and may break extant test definitions. There isn't a simple way to continue using the name auto-tag without breaking previous workload templates. The behavior is too unintuitive and ambiguous to leave in as-is. Thus, the name op is selected, and seems a more desirable (aligned with extant structure) anyway.
At the very least, users who have any tag filter including name should be given an error that is specific to the change so that they can update it.

This may have been fixed in the current code. It needs to be verified and a test added in any case.

block, name, and op tags are automatically generated and available.


Added Pureact

Suggested adding Pureact which only has one dependency - Snabbdom.

Looks cool! Thank you for sharing the project :smile:


Update fblldb.py

fix Xcode 10 import script failed

Thanks for the pull request. This looks fine to merge but I do wonder if there's a root problem elsewhere? I use Xcode 10 Chisel has worked for me. Also there have been no other reports of loading chisel in Xcode 10


require error from opal

I added a gem to my gemfile and required it in the main_controller
When i load the page i get
Opal::Builder::MissingRequire: A file required by "app.rb" wasn't found.
A file required by "main/lib/main_view" wasn't found.
can't find file: "salama" in ["//opal-0.7.2/opal", "//opal-0.7.2/stdlib", "//opal-0.7.2/lib", "/Users/raisa/salama/opal-pixi/lib", "/Users/raisa/salama/salama-debugger/app", "//volt-0.9.4/app", "//volt-0.9.4/lib", "//volt-bootstrap-0.0.10/app", "//volt-bootstrap-0.0.10/lib", "//volt-mongo-0.1.1/app", "//volt-mongo-0.1.1/lib"]
//opal-0.7.2/lib/opal/builder.rb:45:in rescue in build_str' 	//opal-0.7.2/lib/opal/builder.rb:38:in build_str'
//volt-0.9.4/lib/volt/server/component_handler.rb:31:in `compile_for_component'
(ps, shortened paths for readability)
The reason i think this is a bug, is that i have the same procedure with opal-pixi, and that works.
The trace mentiones opal-pixi in the load path, but not my gem, which is salama.
The code is here: https://github.com/salama/salama-debugger
just the normal bundle, volt s
Thanks for any help. I read all the docs but couldn't find anything
PS: tried on gitter, but gitter was down or wobly (or the net) and my timezone window is closing.

@dancinglightning salama looks like an interesting project.  You would know better than me if it will compile on the client side.  You probably need to get it's lib on the opal load path.  Try doing this in app/main/config/initializers/boot.rb
unless RUBY_PLATFORM == 'opal'
  lib_path = Gem.loaded_specs['salama'].full_gem_path + '/lib'
 Opal.append_path(lib_path)
end

That should add it to opal's load path.  (I need a better way of doing this obviously :-)  Let me know if that works.  Thanks

@dancinglightning totally unrelated, but have you seen github.com/whitequark/parser  Its a full ruby parser written in ruby with almost no dependencies.

@ryanstout thanks for the tip, i had found as far as Opal.append_path.
Part of the reason i opened this as an issue was the fact that i had read all the docs and still got this.
So i think you should either put this in the docs, or auto-append or find some mechanism in the dependencies where one could just say (eg)  client_gem("salama") and it would go through the dependencies and do this for all.
Thanks for the project comment, and yes it is very interesting.
And yes i know about the whitequark parser, which i find cryptic, so i didn't want to use it.

@dancinglightning yea, I tried to auto include all gems in the opal path, but thats a bad idea for a few reasons.  I'll probably add a gem option to dependencies.

great.
And i would think some docs update quite soon, because this behaviour is
contrary to what docs say and may put many people who just try volt out off.
If you want a hand, i could spend an hour for all this time you're
helping others like me :-)
Ryan Stout wrote:

@dancinglightning https://github.com/dancinglightning yea, I tried
to auto include all gems in the opal path, but thats a bad idea for a
few reasons. I'll probably add a gem option to dependencies.
—
Reply to this email directly or view it on GitHub
https://github.com/voltrb/volt/issues/246#issuecomment-120455685.

just for completeness, the code works.
but not in the initializer (or in the controller). But if i put it in config/app.rb it works.


[Event Request] Table 7000 "Price List Header" - UpdateStatus

🕮 Describe the request
I want to skip the "Confirm New Status" Message when activating a price list.
Old:
        if ConfirmManagement.GetResponse(StrSubstNo(StatusUpdateQst, Status), true) then              PriceListLine.ModifyAll(Status, Status)         else             Updated := false
New:
New local Variables
Confirmed, IsHandled: Boolean
`OnUpdateStatusOnBeforeConfirmStatus(Rec,Updated,Confirmed,IsHandled);
if Not IsHandled then
Confirmed := ConfirmManagement.GetResponse(StrSubstNo(StatusUpdateQst, Status), true)
if Confirmed then
PriceListLine.ModifyAll(Status, Status)
else
Updated := false
[IntegrationEvent(false,false)]
OnUpdateStatusOnBeforeConfirmStatus(PriceListHeader: Record "Price List HEader",Updated: Boolean,var Confirmed Boolean, var,IsHandled: Boolean);
begin
end;`
Additional context
I want to skip the "Confirm New Status" Message when activating a price list.
Alternative: New Function GetConfirmation with handled pattern.
Also think about adding the price list code to the question, with automated procedures, you don't know the context of the pricelist

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11755.


Handicap games - rated?

It looks like for Shogi, I can choose a handicap, but I can still select rated and create a game... I haven't checked to see if that actually goes through to a real handicap game, but once that's selected that shouldn't be an option.
Similarly, I can still put an FEN in any variant and still have the option to choose rated.
Maybe what would make sense is that if you have rated selected, the FEN and handicap dropdown list should be grayed out? And if you choose a handicap or FEN, then casual should automatically be selected

Fixed. Thx!

LOL I don't know why I put this here, whoops!


Stateful node installation.

Start brain storming how stateful node installation will work.  Thoughts on what might be needed:

[ ] Disk Layout(s)
[ ] how to select the disk(s) to use in a layout
[ ] how to select the mode for a node, (stateful vs. stateless)
[ ] how to disable netboot for a node after stateful image is written to disk
[ ] boot loader and control whether it gets a pxe or not
[ ]

Disable netboot should be a call to the mPCC just before it hands control over to systemd to disable the bootable flag on all nics.

bootloader: need to be able redirect image to a disk if it is stateful.  mprov initramfs?  Can we add API key to the initramfs? No python in initramfs, might need to be a wget or a curl to get device to redirect to.

stateful vs stateless will be a flag to the system (db mod)

Disklayouts are associated with disks which in turn are associated with systems

Do we need software RAID support?


Move more types to generic, reduce direct dependencies with local interfaces, update CI

Codecov Report

Merging #14 (6139b48) into master (b5349b1) will decrease coverage by 3.96%.
The diff coverage is 48.38%.

@@            Coverage Diff             @@
##           master      #14      +/-   ##
==========================================
- Coverage   62.66%   58.70%   -3.97%
==========================================
  Files          14       15       +1
  Lines        1058      741     -317
==========================================
- Hits          663      435     -228
+ Misses        354      284      -70
+ Partials       41       22      -19

Flag
Coverage Δ

unittests
58.70% <48.38%> (-3.97%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

evict.go
0.00% <0.00%> (ø)

evict_go1.18.go
0.00% <0.00%> (ø)

failover.go
74.66% <0.00%> (-8.00%)
:arrow_down:

http.go
24.48% <0.00%> (-20.04%)
:arrow_down:

trait.go
70.45% <60.00%> (-10.07%)
:arrow_down:

trait_go1.18.go
61.36% <61.36%> (ø)

failover_go1.18.go
47.05% <72.72%> (-2.28%)
:arrow_down:

sharded_map_go1.18.go
37.87% <75.00%> (-0.64%)
:arrow_down:

sharded_map.go
78.62% <100.00%> (ø)

sync_map.go
88.70% <100.00%> (+4.98%)
:arrow_up:

... and 6 more

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 b5349b1...6139b48. Read the comment docs.


Multichip Hang With Watcher Assert

Run the following command on a T3000:
pytest tests/tt_eager/python_api_testing/unit_testing/misc/test_all_gather.py -k "post_commit and looping and  200-mem_config1-input_dtype1-8-1-input_shape2-3-layout2"
from branch snijjar/issue-6363
You'll hit this error:
2024-03-13 16:37:39.918 | INFO     | tests.tt_eager.python_api_testing.unit_testing.misc.test_all_gather:run_all_gather_on_t3000_impl:99 - dim: 3
              LLRuntime | INFO     | Watcher checking device 3
              LLRuntime | INFO     | Watcher checking device 2
              LLRuntime | INFO     | Watcher checking device 6
                 Always | WARNING  | Watcher stopped the device due to bad NOC unicast transaction
                 Always | INFO     | While running kernels:
                 Always | INFO     |  brisc : tt_metal/impl/dispatch/kernels/cq_prefetcher.cpp
                 Always | INFO     |  ncrisc: blank
                 Always | INFO     |  triscs: blank
                 Always | INFO     | Last waypoint: NAWW,W,W,W,W
                 Always | FATAL    | On core (x=2,y=9): brisc using noc0 tried to accesss core (00,03) L1[addr=0x800000000,len=4]

what is the reason for P0 for this issue? (P0 is pretty disruptive).

@davorchap Suggested I bump up this item since it is blocking all-gather changes from getting into main (and having knock-on affects as a result - model perf, blocked, other feature development, burning dev time, etc.).

I agree P0 is touchy though, so let's chat if there is push back on that.

i think that is a good reason for me. @davorchap  is right. I agree with it.

Pushed a fix to address the watcher error. Confirmed that if we synchronize after every op invocation, it passed, but it hangs if we don't block. Can you confirm this workaround works for you?
If so, you can make a new issue to address the new problem and assign to me.

Opened issue for part 2 of debugging: #6404
I also checked in my fix commit, so maybe see if there is a way for you to merge.

The hangs we're consistently seeing with program cache enabled on remote chips, is due to bidirectional tunneller not observing the max cmd slots for tensix cores, therefore it can end up in a deadlock scenario where the issue path is trying to forward more cmds when the remote pull and push kernel is blocked trying to send cmds back through the completion path.
With fix bdc566044, I am able to run the test here many times, no hangs. I also tried Falcon40B 60 layers with program cache on 8 chips, it's now passing consistently.
The bug can affect any remote chip test (e.g. device 4,5,6,7 on T3000), please try commit with any reported hangs.

This is fully resolved I believe


Please Delete pycache from GitHub

Hi,
Thanks for this. However please delete pycache form the github. After the custom node install, i was getting black images. Then understood, it messed up comfy nodes.py because my python versi0on is different. I deleted that folder and relaunched comfy and it created new init files in pycache
And it working again. Some people might not know this and blame the node as if the ndoe broke comfy when thats not the case.
Thanks.

Indeed, that is the case.

Thanks for reminder！ done

pychae deleted


Fix bugs in emigration rate calculation

NOTE: This makes code changes that have not yet been run on a very large population. My plan here is to get any feedback on the code before starting the run, which takes quite a bit of resources.
The bugs:

The at risk population was not being calculated correctly.
The indexes were not being matched up correctly when applying the proportions, leading to a substantial underestimate of the rates.

In order to address the second bug I have pulled in more code from VEHSS that does the distributing-by-proportions operation.

Hey @zmbc , I started looking over this, but there's a lot here that I'm not familiar with. If you want feedback on it, I think it would be easiest if we met to go over it together so you could explain what's going on and which parts I should pay most attention to.

@NathanielBlairStahn thanks for taking a look, and sorry for the delay in responding! Let's find a time to discuss.


ES2015 features break IE11

In https://github.com/zeit/title/blob/master/lib/index.js#L26, a default parameter is used:
  str = str.toLowerCase().replace(regex, (m, lead = '', forced, lower, rest) => {
                                                  ^^^^

A couple other ES2015 features, such as the spread syntax, are used as well.
These choices break in IE11. Including an ES5 build, or refactoring the code to avoid ES2015, would fix the issue.

Closing as won't fix for IE11 support 🙏 Thank you regardless!


Plugin updates november 2024

Push November 2024 updates.

Thanks @Sean12mps Approved.

@brandonhundt
Updates deployed to Pantheon.
We just need to make sure that we're only adding those [deploy:live] command for the merge title.

Got it! Thanks for the reminder.


Assist Ilshat with duplicate accounts

Check email, there are 2 accounts created as an organization. Need to delete them both so he can use a personal one.

done


Co-create and submit the iStore ticket with Sorin

Describe the issue
In order to submit the iStore ticket, we need to determine who will be able to receive the device in Calgary.
We need someone at ADSL or hosting services with physical access to CDC in order to receive the AWS Snowcone device.  See the CRM search for "Health Insight" for who to talk on this ticket (Neil S, Rick C, Sorin P)
Additional context

high priority
UPDATE: The Team has sent the ticket to Istore, Kevin is in the mail loop.
The CDC is managed by Equinix
Health intends to use a real dataset from Calgary (the data quality extract)
The DXE and hosting folks will not have likely seen a device like this before.  They will have questions
SecOps might get pulled in as well.  CPF currently has a good relationship with SecOps and we think we may be able to get support quickly (hopefully).

Definition of done

Meet with Julian and Sorin P to share the settings with Sorin, have him create the ticket in his name (because there are charges associated with the ticket) (DONE)
Help Health create iStore ticket (ask for 20h consultation - they will quote), meet DXE (via the iStore process)
We need a name and an address to ship the device to
We need an exact delivery date
We might need a service request in iStore or ServiceNow (we want to try avoid iStore and ServiceNow for as long as possible instead reaching out directly to Directors in Hosting - CPF is finding that a lot of tickets are getting lost at the moment)

See ticket #1930 - confirming this and will proceed accordingly once reviewed on provider's end and summary info received

Kevin worked on this and got the draft iStore over to Sorin & co in Rocket Chat channel.  We are waiting for Rick C to add some team members to the channel to provide their feedback on the iStore ticket.  Sorin is away on holiday.

@jon-mc-git to please get up to speed after vacation with the Rocket Chat conversation and reconnect with Sorin to let them know we're still here for them

Got update and ADSL should have proper folks in by next week to get us the needed info

The diagram might be out of date as we've heard now that the data could be coming from Kamloops

Some key ADSL have been away but they have now brought this up among their team and are reviewing how this could be done within their current high security procedures and considering locations necessary within their network infrastructure to allow large transfer rates yet apply considerations for limiting port\connectability for this and possible future cloud data transfer situations.

Brian P is our main contact in Technical Stewardship

Hosting is held up with Advanced Solutions currently on figuring out a solution for this and future requests of the same type (data extraction from DC's by way of data boxes - procedures\processes, security, etc.)

Service development is in process by OCIO - Still in works

This has been unblocked now that the Snowcone service is being kickstarted.  This topic has advanced with Health and meetings have been scheduled to move things forward.  Have discussed elements of what was needed here with Health and they will be working with Hosting for any remainder questions around this.  Closing ticket


embedded link default is at last point

We would like to embed in WordPress the following timemapper to appear at the first point created: http://timemapper.okfnlabs.org/anon/d8wxdd-godan-history#0
Currently its default is at the last point: http://timemapper.okfnlabs.org/anon/d8wxdd-godan-history#13

backend issue that we fixed!


Permit "version" string in content-type header, rebased to 3.4 + test, v2

Replacement for PR #1877.

Closing in favour of PR #1901.


⚠ Hartman Foundation has degraded performance

In 50beb75, Hartman Foundation (https://gordonhartman.com/) experienced degraded performance:

HTTP code: 200
Response time: 2801 ms

Resolved: Hartman Foundation performance has improved in 8eba2ea.


Cannot Login with UPN format

Previous versions of the module allowed users to login with UPN format (user@domain.com). Is this functionality still available with version 6?

I dont believe that go changed.  Are you experiencing issues using UPN?

Yes. I can get login to work as domain\user or by setting Default Domain as just user. However, I cannot get<EMAIL_ADDRESS>to work.

#14
Pull request was made and new release uploaded.  Install update 6.0.2 and see if issue is resolved.

@rbeghin
Any feedback on this?  Wanted to wait on your verification before closing issue.

sorry I've been away from this project. I'll send an update an a couple of days or so. Thanks,

I installed 6.0.2 and I can now login using UPN format. However, if a user had previously logged in the system creates and additional user which looks the same BUT the roles do not seem to have been applied to the new UPN logon.
Example: user1 previously logged in and was added as a user domain\user1. user1 was given the Administrator role. AFTER the update to 6.0.2 I can still logon as user1 or domain\user1 AND I can logon as<EMAIL_ADDRESS>however now an additional user has been created as domain\user1 and the new user is not a member of the Administrator role.
One additional thing, there might be a problem with the installer package. I installed the package assuming that it was an upgrade. It did not upgrade and instead 6.0.0 was still there with an option to delete. Version 6.0.2 appears as another extension BUT it does not have a delete option. I thought maybe there was a problem with the extension installation so I deleted 6.0.0 and then I re-installed 6.0.2 and now I have two versions of 6.0.2 showing as installed. But that said the module is authenticating AD.

Additional problem: after disabling Default Domain in AD's Site Settings, logging in using UPN format no longer works.


When user has set themselves as invisible it shows creation date as last active.

When user has set themselves as invisible it shows creation date as last active.

Desktop Version: 5.11.1

What were you expecting to see there?

I'm not sure, but could we just remove the date in this case?

Previously it would show when the user set themselves as invisible but now it shows creation date.


Cargo not running integration tests on cargo test if version number is big, i.e. 5123.0.0

Problem
I was surprised to find out that the integration tests located within the tests sub-folder were not being executed when the version was as big as specified in the title, but when a 'normal' value was used, everything ran as expected.
Steps

Create a test within tests.
Set the version of the crate to a big number, i.e. 5123.0.0.
Run cargo test.
Observe that the tests within tests do not get executed.

Possible Solution(s)
No response
Notes
It looks like a boundary issues, so the mistake may be on my part for exceeding an existing limit within Cargo's code.
Version
cargo 1.78.0 (54d8815d0 2024-03-26)
release: 1.78.0
commit-hash: 54d8815d04fa3816edc207bbc4dd36bf18014dbc
commit-date: 2024-03-26
host: aarch64-apple-darwin
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.4.0 (sys:0.4.72+curl-8.6.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 14.3.1 [64-bit]

I cannot reproduce with the following commands:
cargo new foo --lib
cd foo
echo "[package]" > Cargo.toml
echo "name = 'foo'" >> Cargo.toml
echo "version = '5123.0.0'" >> Cargo.toml
mkdir -p tests
touch tests/bar.rs
cargo +stable t

And got this output:
    Creating library `foo` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
   Compiling foo v5123.0.0 (/home/user/repos/foo)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.28s
     Running unittests src/lib.rs (target/debug/deps/foo-f82fbcf55ac84707)

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/bar.rs (target/debug/deps/bar-70708f1a8f83e042)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests foo

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Would you mind sharing a minimal reproducible example of it, and also the console output you've got from Cargo that had this issue?

Without a reproduction case, I'm going to go ahead and close this.  If you end up coming up with one, let us know!


Drop comma in def_node_search

In bbatsov/rubocop's master branch, comma is not allowed in node pattern.
See. https://github.com/bbatsov/rubocop/pull/4499

Oh good catch. Thanks!


directory inconsistency between GUI and CLI/TUI based on profile name

GUI behaviour : If I use a non-default profile the gui creates a folder with the same name and puts everything in subfolder called main in there, so into ~/.epic/[profilename]/main/ .
CLI behaviour: If i start the epic-wallet with argument -a [profilename], it expects the files in ~/.epic/[profilename]/ (no subfolder main) and complains about missing wallet_data
I know the -t argument can work around this, however, I find the differing default behaviour of the two wallets not intuitive for new users.

The gui wallet is creating a complete new wallet database and settings within a subfolder "[profilename]/main" and a "default" cli account
The cli command "-a" is a sub account command for the main wallet. You can create multible sub accounts in cli that all depends on the default main account.
If you want use the cli to get data from a gui wallet folder structure there is no way arround to use parameter -t.


fix: Convert nanos to seconds

Noticed that my metrics were off with a factor of 10.
scala> 10e-9
val res0: Double = 1.0E-8

scala> 1e-9
val res1: Double = 1.0E-9

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Would you mind take a look at this, @toxicafunk?


import_open_qasm import S gate error

Describe the bug
Attempted to import multiple circuits from qasm, all circuits containing s gate failed to import.
TypeError: Phase() got multiple values for argument 'target'
The error message showed that this is due to part of parse_command() in qasm.py
if name in ("s", "t", "sdg", "tdg"):
        g = gates.Phase(pi / (2 if name.startswith("s") else 4),
                     control=None,
                     target=get_qregister(args[0], qregisters))
        if name.find("dg") != -1:
            g = g.dagger()
        return g

Changing this to
if name in ("s", "t", "sdg", "tdg"):
        g = gates.Phase(angle = pi / (2 if name.startswith("s") else 4),
                     control=None,
                     target=get_qregister(args[0], qregisters))
        if name.find("dg") != -1:
            g = g.dagger()
        return g

fixes the issue
To Reproduce
Steps to reproduce the behavior: Ideally an executable code snipped like
import tequila as tq

tq.import_open_qasm(
    '// Generated from Cirq v1.3.0\n\nOPENQASM 2.0;\ninclude "qelib1.inc";\n\n\n// Qubits: [q(0), q(1), q(2), q(3)]\nqreg q[4];\n\n\nu3(pi*1.5,pi*2.0,0) q[0];\n\n// Gate: CZ**-1.0\nu3(pi*0.5,0,pi*1.25) q[0];\nu3(pi*0.5,pi*1.0,pi*1.75) q[1];\nsx q[0];\ncx q[0],q[1];\nrx(0) q[0];\nry(pi*0.5) q[1];\ncx q[1],q[0];\nsxdg q[1];\ns q[1];\ncx q[0],q[1];\nu3(pi*0.5,pi*1.25,pi*1.0) q[0];\nu3(pi*0.5,pi*0.75,0) q[1];\n\nu3(pi*0.5,pi*1.0,pi*0.5) q[0];\nu3(pi*1.7198391408,pi*1.5,pi*0.5) q[2];\nu3(pi*1.5,pi*1.1295046702,pi*0.8704953298) q[3];\ncz q[2],q[3];\nu3(pi*1.5,0,0) q[2];\nu3(pi*1.5,pi*1.1295046702,pi*0.8704953298) q[3];\ncz q[2],q[3];\nu3(pi*0.6295046702,0,pi*0.5) q[2];\nu3(pi*0.7198391408,pi*0.5,pi*1.3704953298) q[3];\n'
)

Expected behavior
Should import s gate without error
Computer (please complete the following information):
tequila version:  1.9.4
python version:  3.10.13 (main, Feb  6 2024, 19:53:26) [GCC 9.4.0]
platform:  #19~22.04.1-Ubuntu SMP Wed Jan 10 22:57:03 UTC 2024

Hi,
Thanks for the feedback. Since it appears that you have solved the issue already yourself, would you be interested in making a pull request to fix the issue? I usually prefer this, because the git log then credits you for solving.

Should work now. Please let me know if not. Tanks for reporting!


Make pip installable

I needed to make opendr pip install -e .able in order to track down a test failure in core; fixed lint while I was at it. This is a huge diff, but most of it is minor lint changes. Look at commit 	8eea8ab for the changes related to pip and the following commits for lint fixing. Tests are passing in circleci: https://circleci.com/gh/bodylabs/opendr/401

Weirdly, github wants to include every commit ever in the diff... I can open the PR on bodylabs/opendr directly and then we can merge it up if that'd be an easier way to do this.


MSGEQ7 support

This is a nice chip which enables the possiblity to sync music with LED animations.
Would be awesome if this would support it.

Thanks much for the ideas! I'd love to do a project like that in the future, but I'll probably open a new repo as that'll be a pretty different code base.  Cheers!


Warn if buffers are used

Since users seem to stumble over this, and since it is not obvious in a lot of SYCL teaching material, this PR adds a warning when a buffer is used for the first time in an application recommending users to switch to USM.

Would it be possible to have an env flag to disable the warning ?

We have that - ACPP_DEBUG_LEVEL will do it for a sufficiently low setting. Will that work?
Also, it only prints the warning the very first time a buffer is used in an application, so you will not be bombarded with warnings either way.

it is enabled for ACPP_DEBUG_LEVEL >= 1 i guess ?
That should be fine.

Yep, same as any other warning. And as I said, you would never see this warning more than once per application run, similarly to e.g. our JIT warning. So I don't think the warning would be too distracting.


BSON serialization from getServerSideProps

Feature request
Is your feature request related to a problem? Please describe.
getServerSideProps has been a huge help, and it would be an even bigger one if it allowed us to return objects containing BSON, for instance results from a query to a MongoDB database.
Describe the solution you'd like
I would like the serializer that's called at the end of getServerSideProps to handle BSON just like the one called in API routes when I do res.json(...).
Describe alternatives you've considered
Right now, in getServerSideProps I call an API route that does the database fetching and the serializing, so that I can insert the json from that route into the returned props.
But it won't work, for instance, when I want to serialize context.req.user which I define in my authentication middleware.
The alternative would be to call manually a BSON-compatible serializer before returning the props. But since Next.js seems to already have on at hand for the API routes, I thought maybe we could just use the same one.

Ok I just realized that the serializer on the API routes was just JSON.stringify.
So for instance in my case this works:
export const getServerSideProps = async (context) => {
  return { user: JSON.parse(JSON.stringify(context.req.user)) }
}

but this doesn't:
export const getServerSideProps = async (context) => {
  return { user: context.req.user }
}

It would be nice if we could use the second syntax :)


QueueItem.getExecutable() returns null after server.getQueueItem(queueRef);

Hi,
it seems that the current implementation of the java-client-api is not able to start jobs on a current jenkins instance. We are using Jenkins 2.46.2 and the java-client-api 0.37.
Our code looks like this:
QueueReference queueRef = job.build(true);
QueueItem queueItem = server.getQueueItem(queueRef);
job= job.details();
...
Build build = server.getBuild(queueItem);

The last code line does not work and ends with a NPE:

java.lang.NullPointerException
at com.offbytwo.jenkins.JenkinsServer.getBuild(JenkinsServer.java:810)

The same behaviour can be reproduced with:
JenkinsTriggerHelper triggerHelper = new JenkinsTriggerHelper(server);
BuildWithDetails build = triggerHelper.triggerJobAndWaitUntilFinished(job.getName(), true);

We found following workaround:
QueueReference queueRef = job.build(true);
QueueItem queueItem = server.getQueueItem(queueRef);
while (queueItem.getExecutable() == null) {
       Thread.sleep(ViewerWaitForJob.waitForPollingInterval / 10);
       queueItem = server.getQueueItem(queueRef);
}
job = job.details();

We poll queueItem.getExecutable() until its not null.

This is related to issue #230

Hi,
@khmarbaise How is this issue related? There is no concurrency involved in the code provided by @rpionke
I have stumbled on the same problem, no concurrency involved in my code.

@khmarbaise I had the same problem，how to resolve it?

I have the same issue...

using version 0.38.
And in the JenkinsTriggerHelper, I find the method
JenkinsTriggerHelper.triggerJobAndWaitUntilFinished(String jobName, QueueReference queueRef)
still use these code to get the build while I still get the NPE.
So I have to implement the triggerJobAndWaitUntilFinished to get the corrent build using :
// ....
Build before = job.getLastBuild();
job.build(param);
Build build = job.getLastBuild();
while (before.getNumber() == build.getNumber()) {
       //... some codes to exit the loop
      Thread.sleep(5000);
      build = server.getJob(jobFullName).getLastBuild();
}
// ....

Hi,
I'm facing the same issue. I'm trying to trigger a parameterized pipeline using this method.
JenkinsTriggerHelper.triggerJobAndWaitUntilFinished(String jobName, Map<String, String> params)
I'm getting a NPE here
Build build = server.getBuild(queueItem);
using version 0.3.8


Forgejo installs now have theme issues, lack theming

I've been having issues with the theme on my Forgejo installs and have just figured out why.
(I note https://git.l3d.ch/ appears to show the same issue.)
I left the gitea_theme_default and gitea_themes undefined in my vars and just fell back onto the defaults defined by this role:
  gitea_theme_default: auto
  gitea_themes: auto,gitea,arc-green

But Forgejo no longer seems to provide gitea or arc-green themes in the default install and the default auto theme is now called forgejo-auto. There seems to be some theming if you leave everything as default but change the settings > appearance to one of those themes and there is now way to get back to a working theme (except presumably editing your account settings in the database..).
The solution was to define those two vars in my setup and rerun the role.
  gitea_theme_default: forgejo-auto
  gitea_themes: forgejo-auto

Then go to settings > appearance and set the theme to forgejo-auto.
Another fix that needs documenting? Also relevant to issue #147 I think.

The current default theme names are incorrect in the role. I switched them out the following and now it uses the default gitea themes.
gitea_theme_default: gitea-auto
gitea_themes: gitea-auto

https://docs.gitea.com/administration/customizing-gitea

Ah yes, and Forgejo still ships the Gitea themes as well as Forgejo variants, so that's a sensible fix. I can work up a pull request unless someone beats me too it...
The full list of Forgejo default themes, including several colourblind friendly variants can be found here.

I can reproduce the lack of theming on Gitea as well as Forgejo.

Untested as yet, but WIP using Jinja2 if statement to customize theme vars in my fork.

@carranzamarioagustin Can you test my suggested changes in Gitea? This Pull request works well with Forgejo but I have no testing setup for Gitea.


XML variable substitution: log each substituted variable

Troubleshooting
Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting
Environment

TFS on-premises

Issue Description
Current the only thing we see in our logs when we use XML variable substitution is:

XML variable substitution applied successfully

We'd like some more logging. Specifically which variables in which files are replaced . When you run the deployment task in debug mode (System.Debug set to true) this information is available, but we don't want to run everyting in debug mode.

@lzandman Thanks for the feedback. We will incorporate this in our backlog. We will display what fields have been transformed in the normal logs itself.
Though this may take some time as we are prioritizing issues which have major customer impact.

Hi, We have made the necessary changes. Please feel free to reopen the issue in case you have any doubts.


Dataproc serverless test fixes

Contributes to #10347 .
This fixes a handful of the integration test failures in the Google Dataproc Serverless environment. For the cast_test.py failures, the exception is actually on the CPU run of the tests, so we skip the tests in the serverless environment. For the join_test.py failures, BatchScanExec was not actually added to the allow_non_gpu mark, even though it was falling back to CPU, so it actually needs to be added to this mark.

build


Make the data tidy

Sit down and write a script to make the data tidy for anyone else who wants to use it to save them the trouble.
Make a new directory, clean_data, and rename current data to raw_data

This is technically complete.  New Issues will be more specific with acceptance guidelines.


Add workaround for Clang/Catch2/libstdc++ issue

Catch2 CHECKs involving tuples fail on Clang with libstdc++ when using C++23 mode, which enables new tuple comparisons operators.
See this Clang issue: https://github.com/llvm/llvm-project/issues/113087

/ok to test


After Clearing the Error in Visualforce Page Still showing In Errors list

Errors list is not cleared. Especially this is occurs with VF pages, but fine with Apex. how can I clear the errors plane

What is Visual Force and what is Apex? Can you provide more information and perhaps some screenshots?

I have Integrated mavensmate with atom. Witch acts an interface between IDE and Salesforce.
In salesforce we have Apex(Controller) and visualforce(View).

@naveenila1221 From what I can tell, this behavior isn't anything to do with Atom itself and is provided by one or more community packages you have installed. You may want to determine which community package you have installed that isn't working the way you expect and contact the authors of that package. The Atom FAQ has information on how to contact the authors of any Atom community package or theme.


[FLINK-3257] Add Exactly-Once Processing Guarantees for Iterative DataStream Jobs

Motivation and Algorithm
This is a first version of the adapted snapshot algorithm to support iterations. It is correct and works in practice...well, when memory capacity is enough for its logging requirements but I am working on that, hopefully with a little feedback from you. Before we go into the implementation details let me describe briefly the new algorithm.
Algorithm
Our existing checkpoint algorithm has a very fluid and straightforward protocol. It just makes sure that all checkpoint barriers are aligned in each operator so that all records before barriers (pre-shot) are processed before taking a snapshot. Since waiting indefinitely for all records in-transit within a cycle of an execution graph can violate termination (crucial liveness property) we have to...save any unprocessed records for later and get done with the snapshot. In this take of the algorithm on Flink we assign that role to the Iteration Head. The steps this version varies from the vanilla algorithm are simply the following:
(1) An Iteration Head receives a barrier from the system runtime (as before) and:

Goes into Logging Mode. That means that from that point on every record it receives from its Iteration Sink is buffered in its own operator state (log) and not forwarded further until it goes back to normal mode.
Forwards the barrier to its downstream nodes (this guarantees liveness, otherwise we have a deadlock).

(2) Eventually, the Iteration Head receives a barrier back from its Iteration Sink. At that point:

It checkpoints the log as its operator state.
Flushes to its outputs all pending records from the log and resets it.
Goes back to normal forwarding mode.

(3) When the Iteration Head starts/restarts it looks at its initial operator state (the log) and flushes any records that are possibly pending.
Example
This is just a very simple example topology. We have a single source S and a mapper M within an iteration with a head H and tail T. This is the bare minimum we need for now to check how this works.

In the diagram below you can see the sequence of possible events, containing both barrier and record transmissions. For completeness I included the Runtime as a separate entity, this is in our case the Checkpoint Coordinator who periodically initialises checkpointing in all tasks without inputs.
The point that this diagram tries to make is the following:
Record R1 (or any record received in normal mode) gets forwarded to M, the only consumer of H before the checkpoint barrier. On the other hand, R2 is not forwarded to M until H has finished snapshotting (or during the same atomic block anyway). In case of a failure R2 is not lost, rather than saved for later.

A very brief description of a consistent/correct snapshot in our context could be summed up in the following sentence:

Every record prior to a snapshot has been either processed by an operator (state depends on record) or included in the snapshot as event in transit (see Chandy Lamport algorithm).

This algorithm guarantees this property and as explained earlier, it also terminates.
Current Implementation Details
In the current prototype I tried to keep changes to a minimum until we agree on the pending issues (see below) so there is plenty of room for improvement, engineering-wise. The important changes are the following:

Obviously there is no more checking for iterations during a fault tolerant StreamGraph construction.
the triggerCheckpoint function of StreamTask was split (please do not freak out). That was necessary in order to extract the checkpointing logic from the barrier handling logic (which should be obviously decoupled in the updated algorithm). The actual state snapshotting now happens inside checkpointStatesInternal.
The StreamIterationTail has to process and forward Either<StreamRecord<IN>, CheckpointBarrier> objects to StreamIterationHead which takes the necessary steps depending on the event according to the algorithm. An internal task abstraction ForwardingOneInputStreamTask was introduced for forwarding barriers to the tail.
The StreamIterationHead uses a simple UpstreamLogger operator internally for its logging needs, nothing special about it.
A StreamIterationCheckpointingITCase was added that checks exactly-once guarantees, loops included. More tests will follow upon demand.

I am sure we can improve this implementation but let's focus on the non-trivial problems first.
Open/Pending Issues
During stress-testing I found the following issues that we need to discuss hoping that some of you are maybe eager to propose something.

I realised that while flooding my cyclic topology with records I was still losing data, even at the absence of task failures. The problem seemed to be the way we transferring events from the StreamIterationTail to the Head. Apparently the tail offers records to the head with a specified  timeout on a blocking queue of size 1(!?). What is going on there? The Head makes sense to timeout on reading, but, why does the StreamIterationTail throw away events like there is no tomorrow?
Since at-most-once processing guarantees are not what we want I just commented out the offer part until I understand why it is there. I think it is safe (deadlock-wise) to simply put records to the queue, right?...I can also fire a new JIRA issue reporting this if needed.
I feel that we really need to spill log state to disk (BufferSpiller?), or/and restrict iterative jobs to out-of-core backend and forbid in-memory. The upstream log size can very easily pass the boundaries of the allowed in-memory state (e.g. when millions records in transit are snapshotted). Any ideas on that are welcome!

Thanks a lot for looking into this. Really looking forward to your suggestions.

Thanks Paris, I like the idea, it's a correct modification of the original algorithm to make it much easier to implement on Flink for the price of buffering more records.
I have some comments to the implementation:

Why did you introduce the ForwardingOneInputStreamTask if only the Iteration tail will implement this behaviour? I am not sure if other StreamTasks will do this in the future, so it might be better to just put the logic in the StreamIterationTail instead of adding a new abstraction
I think the RecordPusher and UpstreamLogger embedded operators on the head and tail tasks are not really necessary and just add additional complexity to debugging and understanding the code. The Upstream logger only makes checkpointing "easier" for the implementer but we probably want to do some custom logic there anyways. So I would probably just overwrite the checkpointStatesInternal method directly.

I agree that we definitely need to spill the buffered records to disk or use managed memory for this. This can be similar to the BarrierBuffer logic. We can combine this with checkpointing to an output stream to never have to materialize the full state.

Thanks for going through it Gyula!
I agree, the ForwardingOneInputStreamTask can be integrated in the StreamIterationTail, I will probably do that. I just wanted to get the code look less messy in the tail part but you are right.
About the operators, the RecordPusher was already there (even though it was not initialised correctly). I just added the UpstreamLogger because I wanted it to follow the operator lifecycle. I think the way it is we do not need to override the checkpointStatesInternal to do the changes we discuss. We just need to change the operator callback method and this could also be more robust to changes in the StreamTask and operator interfaces and default behavior, just my personal view but I see your point too.
I agree with the spill buffer logic. I am only confused a bit with the output stream thing (the other part of the problem), is there something already I can use? I haven't check recent changes. How does this work if we use in-memory backend for example? The blob with all the messages will be anyway packaged and sent within the stateHandle to the job manager in a single message (potentially being over the limits), even if we use a stream API, or?

Great idea @senorcarbone. I also really like it :-)
I agree with @gyfora to include the logic of the ForwardingOneInputStreamTask in the StreamIterationTail.
For the spillable state we can only use the RocksDBStateBackend at the moment. But I think that is fine for a first iteration. Eventually, we'll also add managed memory support for the memory based state backends which will make them equally suitable for the task.

Thanks @tillrohrmann for the feedback!
I merged ForwardingOneInputTask into StreamIterationSink.
One more think I missed pointing out is that when the iteration timeout occurs the StreamIterationHead flushes its log to its output before terminating. An alternative take would be to delay termination until the barrier arrives back to complete the snapshot. The problem with that version, even though it's correct, is that under frequent checkpoint intervals the iteration head could potentially never terminate because it will always be in snapshotting state when the timeout occurs.
Regarding the state snapshotting, should I switch to using the ListState representation instead or does it make no difference for the time being?

I can't really add anything to the timeout question :D
As for the snapshotting. I would go with the ListState as that potentially provides very efficient implementation for this logging phase. (It is actually designed to handle this) Then we don't have to worry about spilling there either.

You can find an alternative version using ListState in the following branch:
https://github.com/senorcarbone/flink/commits/ftloopsalt
So I noticed that this version is quite slower than the one with custom operator state but it can support larger states apparently.
I am (ab)using the PartitionedState to store the ListState in the same key, as @gyfora suggested since it is the only way to obtain the nice representations at the moment. It would be nice to have them available for operator state snapshots as well - @aljoscha have you thought about it? When there is free time (after the release) it would be nice to see what @aljoscha and @StephanEwen think of the two takes as well. No hurries, just take a look when you have time!
The two annoying issues I noticed during testing and we need to check soon are the following:

The overhead of transmitting and finally delivering a barrier from the head to its consumers increases in time (for each subsequent checkpoint). That is due to having a single queue at the beginning of the iterative part of the job. Events coming from the backedge are pushed further behind the input queue.  It would be nice to have take events in round robin among the two input gates (iteration source, regular input). Otherwise, checkpoints in iterative jobs can be really prolonged in time due to this.

We need a proper way to deal with deadlocks. I removed the part where we discard events in the tail upon timeout since that boils down to at most once semantics. This PR is not solving deadlocks but I think we should find a graceful way to tackle them. (@uce, any ideas? )

The core idea of this is very good, also the illustration is very nice.
After an offline chat with @senorcarbone, we concluded that a remaining problem in this is currently the way it integrates with the timeout-based termination detection.
Which brings us to the point that we should (in my opinion) change the way that loops terminate. It should probably be based on end-of-stream events, to make it deterministic and not susceptible to delays.
Question is now, does it make sense to do the termination change first, and base this on top of it, or to merge this irrespective of that...

Thanks @StephanEwen and @uce for looking into it! I really appreciate it. How about the following:

I update this PR with the patch that uses ListState and apply some nice refactorings Gyula made
I will also address all your comments and then merge this to master
We start working on perfecting stream finalization on loops and backpressure deadlock elimination in seperate PRs right away. These are different problems and we need to address them separately, in my view of course.

Sounds like a reasonable approach Paris! Just ping here after you addressed 1. and 2.

ok good to know @uce! Let me get back to it in a couple of weeks and make it right, now it is a bit impossible to find time.

Hey! Good to be back :) . Let's fix this properly, as @StephanEwen recommended it now that there is some time.
We are writing together with @FouadMA a FLIP to address major loop fixes. Namely, termination determination and fault tolerance. The termination implementation is already in a good shape in my opinion and you can find it here so you want to take an early look. The description in the FLIP will make clear of how this works in detail.
The FT update for loops will be rebase on top of the loop termination fix.
We hope that you will find this good too and btw thanks for your patience :)

Ok, so I am progressing this a bit independently from the termination stuff and then we rebase to the first PR that is merged. I just changed everything and rebased to the current master.
Some notable changes:

The StreamIterationCheckpointingITCase is not made deterministic, it fails after the first successful checkpoint once and the jobs stops after everything has been recovered appropriately.
I am now using ListState which is supposed to work like a charm with the rocksdb file backend. Note that with the default in-memory backend there is a high chance to get issues given the low memory capacity that it is given by default.
One tricky part that can be potentially done better is the way I set the logger in the StreamIterationHead (had to change the head op field access to protected in the OperatorChain)

Whenever you find time go ahead and check it out. It passes my super-strict test which is a good thing. :)

Hey again, @StephanEwen @uce .
When you have 10 min can you take a look to see if this is acceptable?
I would not like to leave this here for months again, it has been out way too long already.
The changes are just a few and straightforward so I really encourage you to skim them at your earliest convenience. Thanks!

I think the PR looks pretty good, and it sounds fair to to address termination in a later PR as this will still greatly improve the current guarantees without making the backpressure/termination problems any worse.
+1 from me

Exactly, these two issues do not depend on each other.  No doubt loop FT is the first thing that can enable iterations in a production deployment so I would merge that first.
Thank you again Gyula for looking into it :)

Thanks for the reminder, I went over the code today. The code looks mostly good, but here are some thoughts:

The head task supports only one concurrent checkpoint. In general, the tasks need to support multiple checkpoints being in progress at the same time. It frequently happens when people trigger savepoints concurrent to a running checkpoint. I think that is important to support.

There tail task offers the elements to the blocking queue. That means records are simply dropped if the capacity bound queue (one element) is not polled by the head task in time.

With the capacity bound in the feedback queue, it is pretty easy to build a full deadlock. Just use a loop function that explodes data into the feedback channel.

Recent code also introduced the ability to change parallelism. What are the semantics here when the parallelism of the loop is changed?

Since loops did not support any fault tolerance guarantees, I guess this does improve recovery behavior. But as long as the loops can either deadlock or drop data, the hard guarantees are in the end still a bit weak. So that leaves me a bit ambivalent what to do with this pull request.

To suggest some way to fix the guarantees: To my mind, the crux lies in the way that the feedback channel is implemented - a simple blocking queue just does not cut it for that case. To make this proper, I think we need to do the following:

Have an elastic feedback channel (unbounded) with a certain memory budget, that can spill if needed. I think it would be best implemented holding data serialized.
On checkpoint, one simply adds the feedback channel data (already bytes) to the checkpoint
The source task should probably prioritize reading from the feedback channel, to keep it always as small as possible.

These are some good points @StephanEwen, thanks for checking it.
How about the following, regarding each issue:

Concurrent Checkpoints: Looks like an improvement but I can sure do it in this PR if  it is a crucial one. Can you elaborate a bit more or point me out to other concurrent checkpointing operator state examples to get an idea of how you want to do it?
Reconfiguration : Sounds interesting...but I am not really aware of it from the devlist. If it is simple enough I could add support for it here. Otherwise I would suggest we address this in a seperate JIRA and PR as an improvement. Is there a design document on how we plan to achieve reconfiguration and repartitioning for operator state specifically somewhere?
At-most-once blocking queue : It is obvious from my previous comments that I do not approve this part, but that is something we already got rid of in FLIP-15 already (this commit). How about we address this together with the deadlocks in FLIP-15?
Deadlocks: I like the elastic spilling channel idea to resolve deadlocks. I need time to dig a bit more into this and make sure we solve deadlocks and not just improve. Is it ok with you if we address that in FLIP-15? I need more time for this part, plus, we need to combine the absense of expiring queues with a proper termination algorithm (otherwise we just solve the deadlocks and the jobs never terminate).

What do you think?

@senorcarbone I agree, let's fix the multiple checkpoints issue and do the rest in FLIP-15
The other operators have a pretty simply way of doing this:

for synchronous checkpointed operators, no need to do anything, the synchronous part of one checkpoint is over when the next starts (because it is synchronous ;-))
for asynchronously checkpointed state, the state backend needs to be able to hold multiple snapshots, which are saved by multiple background threads
none of the operators deal with in-flight data, which makes their job easy

Dealing with in-flight data probably means that you need to open a ListState for each checkpoint that arrives and add the feed back values to each state, until that particular checkpoints barrier comes back through the feedback channel. I think that should be sufficient.

agreed @StephanEwen! I will do that.

Working on it atm . I decided to make the following optimisations but want to very quickly make sure that async checkpointing works the way I believe it does:

Most importantly, I am changing the iteration head to always forward records. Their effects are not present in any in-progress snapshot anyway so that I should had done from the very beginning. :)
If ListState is checkpointed asynchronously, depending on the backend I suppose, then the current version of it, during the snapshot, will be persisted as a copy, which means that we can apply mutations right away and therefore reset it right after invoking the snapshot to the beginning of the next in-progress snapshot (some indexing involved). That way we do not need to open new ListStates in the first place. Does this make sense?

@StephanEwen Please correct me if I am wrong, regarding the second point. I am just not very familiar with async snapshotting for ListState (this is not clear in the documentation for me). Mind also that I do not use the CheckpointedAsychronously interface, it seems to be heading towards deprecation. Thanks!

@StephanEwen could you check my question above?

The last update implements a variant of what @StephanEwen proposes. We have put some more thought on this offline too thanks to @gyfora ! The idea is that instead of putting records to each ListState, the output log is partitioned into multiple log "slices", one per concurrent checkpoint.
More specifically, the UpstreamLogger operator at the IterationHead slices logs proportionally to the number of concurrent snapshots. This also allows committed output logs to be uniquely identified and cleared after each complete checkpoint. The design is based on the following assumptions:

A slice is named after a checkpoint ID. Checkpoint IDs are numerically ordered within an execution.
Each checkpoint barrier arrives back in FIFO order, thus we discard log slices in respective FIFO order.
Upon restoration the logger sorts sliced logs in the same FIFO order and returns an Iterable that gives a singular view of the log.

Before I polish this we need to close a memory leak. The clear operation of State cleans the state under the registered id but it does not seem to unregister the key itself. Does anyone have an idea on how to unregister state properly? Hope this gets some attention to wrap it up, it's been too long :).

Very interested in this work. It sounds like there are few loose ends and then some cleanup before it might be ready for merge, @senorcarbone or @StephanEwen anything that can be supported by someone else? Would love to help wherever possible

Hey @addisonj.
Sure! You could perhaps review the changes and maybe see how to discard empty operator states if you are motivated. This is the only pending issue for this PR. thanks!

I have just rebased to the current master.
Please let me wrap this up. It has been over a year :)
Unregistering state in the OperatorStateStore is very tiny fix.
@StephanEwen @StefanRRichter Is it ok with you to make this small addition in this PR or should I create a separate issue? Hope you have a spare few minutes to take a quick look this time.

Hey. Any update/opinion/something anyone?
Just a gentle reminder, sorry if this sounds a bit desperate :)

Thanks for the review @gyfora and @StephanEwen , these are very good points.
@StephanEwen makes sense to not really index/keep metadata of individual records in log slices, it is extra overhead. Writing raw operator state makes sense, so I will do that once @StefanRRichter  gives me some pointers, that would be great.
Any redistribution of the checkpoint slices would violate causality so I hope the "list redistribution pattern" actually keeps the set of registered operator states per instance intact. The garbage collection issue still remains but maybe (if @StefanRRichter approves) I can add an unregister functionality to the OperatorStateStore.
I can also add preconfigured operators (not that they will be reused anywhere). It is more clean but I really need to see how can I get full control of the task checkpointing behaviour from the operator level (since the default task checkpointing behaviour is altered at the task-level).

For raw operator state, override AbstractStreamOperator::snapshotState(StateSnapshotContext context) inside your operator.  Your implementation calls to super, then it can obtain the raw stream via context.getRawOperatorStateOutput(). This stream works like a normal output stream, except that you can also call stream.startNewPartition(). This signals that a partition is started and previous partitions are finalized/immutable. Partitions are the atomic units of state redistribution, think of them as the indiviual elements in a ListCheckpointed state.
For restoring, override AbstractStreamOperator::initializeState(StateInitializationContext context). After calling super, context.getRawOperatorStateInputs() provides an iterable with one input stream per partition that your operator should restore.

sweet! thanks @StefanRRichter

Hi. Do we have any updates on this :)

well..major runtime changes are coming with FLIP-6, 15 and 16 so I would suggest you watch those. Loop FT will be included in one of these along with other loop redesign features.

Hi, are there any updates on this feature?

Hi, are there any updates on this feature please?  Loop fault tolerance enables lots of very cool use cases and it would be great to see this incorporated.

I'm closing this as "Abandoned", since there is no more activity and the code base has moved on quite a bit.
I think the feature is still very needed, the Jira issue remains open, and there is also a new FLIP about it: https://cwiki.apache.org/confluence/display/FLINK/FLIP-16%3A+Loop+Fault+Tolerance


Fix Chain Mismatch across YAML files

Issue #, if available:
#30
Description of changes:
The chain list does not match across the template YAML files. This PR adds the missing chains to:
quickstart-chainlink-node.yaml
and
quickstart-chainlink-node-workload.yaml
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This looks like it would fix my issue as well when trying to deploy to Mumbai


[optimize] provide a better defer operator

Proposed changes
will close #5576
Types of changes
What types of changes does your code introduce to Doris?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)
[x] Code refactor (Modify the code structure, format the code, etc...)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have created an issue on (#5576) and described the bug/feature there in detail
[x] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If these changes need document changes, I have updated the document
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

Seems it is similar with class ScopedCleanup in be/src/util/scoped_cleanup.h? why not use it?

@acelyc111
emm... I think "Defer" has a better semantics than "ScopedCleanup"

Seems it is similar with class ScopedCleanup in be/src/util/scoped_cleanup.h? why not use it?

it is similar with class ScopedCleanup,  but more effectively. we shoule union the code chose only one way to use


Pluggable congestion control

Right now this package uses an implementation of TCP-cubic for congestion control. It would be nice if the code easily allowed different congestion control algos to be used.
For example, if I wanted to use a LEDBAT congestion control algorithm, if I were to write my own implementation of the SendAlgorithm interface I still don't see a way to plug that in when I create a new session.
So it would be nice, even if we do not yet have officially supported congestion control other than cubic, to have an easy way to write one and use it instead of cubic.

The reason I'm asking this is specifically for LEDBAT. We need the ability to use cubic cc for some connections, but LEDBAT for others. So if there is already a simple way to do that with this QUIC implementation I'd be interested in that.

I think the options are either having an enum for the congestion controllers we support (which wouldn't allow it to be different on a connection basis), or adding a func (connectionID int64) SendAlgorithm to the quic.Config.
We also have plans to support BBR (#341), and for that we'll need to change the SendAlgorithm interface – so there will be breaking changes at some point.
If you plan to do benchmarks please be aware that some performance-relevant parts of our implementation are still lacking (e.g. loss recovery).

I think having different congestion-control per-connection is not really what I need (sorry for being imprecise), but rather being able to change it per-process.
And yes, I agree having an enum for officially supported congestion controllers is a fantastic idea. I just think even now, before you get around to officially supporting a bunch of different congestion controllers, the code could be rewritten a little to make it simpler to write your own congestion controller and plug it into the session.

SGTM :) If forking is an acceptable solution for now, the relevant line you need to change is https://github.com/lucas-clemente/quic-go/blob/master/ackhandler/sent_packet_handler.go#L69.
Feel free to send PRs to simplify things wherever you think it makes sense – what specifically did you have in mind?


[v3] Enable developer tools in debug mode by default

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

While working on debugging #764, I wanted to see if the Redux store was firing the action I expected it to. While console.log works, it was nice to see the store actions being fired when I was working on them.
I then realized that I would run into this issue in the near future if/when I end up working on some UI work. I thought it'd be nice to enable those two developer tools by default when running in dev mode. This PR adds that functionality
That said, I know this isn't a high priority. No worries in the slightest if this PR is rejected - I'd entirely understand. :)

What is the current behavior? (You can also link to an open issue here)

N/A

What is the new behavior (if this is a feature change)?

N/A

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No, should not impact prod build at all

Other information:

N/A

Ahh I didn't realise the React & Redux devtools weren't being enabled by default, I'd had them running myself (definitely would have struggled without them!) I must have installed them manually 🤔

I have been working in this code base for almost two years without those tools 🤦 (tbf, I knew they existed but was too lazy to look how to install them)


WIP: Set Openmpi FFLAGS Explicity

Checklist

[x] Used a personal fork of the feedstock to propose changes

Currently #5 won't merge. This pull request is a brute force check if the solution proposed by @traversero will fix it.

Done with #9


fix(client): Private timeline doesn't hide certs

In this Pull Request, we are removing the timeline option which says "Your certifications will be disabled, if set to private." as making private doesn't hide the certificates which in turn fixes issue #41171
Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Closes #41171

@moT01 do you mind taking a look at this when you get a moment.


test

@jacobtnyoung did you get this?

did you get this?

@jacobtnyoung did you get this one also?

what about this?

@jacobtnyoung did you get this?

how about now?

@jacobtnyoung how about now?

now @jacobtnyoung


Use prepared statement in TableStatsService / remove cyclic dependency

Codecov Report

Merging #4890 into master will decrease coverage by -0.23%.
The diff coverage is 96%.

@@             Coverage Diff              @@
##             master    #4890      +/-   ##
============================================
- Coverage     82.24%   82.01%   -0.23%
+ Complexity    10676    10644      -32
============================================
  Files          1293     1294       +1
  Lines         44552    44551       -1
  Branches       5632     5631       -1
============================================
- Hits          36641    36538     -103
- Misses         5282     5369      +87
- Partials       2629     2644      +15

Impacted Files
Coverage Δ
Complexity Δ

sql/src/main/java/io/crate/planner/TableStats.java
100% <100%> (ø)
3 <3> (?)

sql/src/main/java/io/crate/planner/Planner.java
88.84% <100%> (ø)
37 <1> (ø)
:x:

...va/io/crate/planner/consumer/ConsumingPlanner.java
100% <100%> (ø)
7 <ø> (ø)
:x:

.../io/crate/planner/consumer/NestedLoopConsumer.java
92% <100%> (ø)
6 <1> (ø)
:x:

sql/src/main/java/io/crate/plugin/SQLModule.java
100% <100%> (ø)
2 <ø> (ø)
:x:

.../main/java/io/crate/planner/TableStatsService.java
90% <85.71%> (+5.25%)
10 <ø> (-1)
:x:

...n/java/io/crate/exceptions/JobKilledException.java
0% <ø> (-66.67%)
0% <ø> (-1%)

...b/src/main/java/io/crate/blob/PutChunkRequest.java
47.05% <ø> (-52.95%)
4% <ø> (-2%)

...va/io/crate/operation/projectors/DMLProjector.java
62.96% <ø> (-14.82%)
4% <ø> (-1%)

...o/crate/operation/projectors/SortingProjector.java
81.57% <ø> (-13.16%)
10% <ø> (-2%)

... and 34 more

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 60a2af9...d8953cb. Read the comment docs.


[Bug] [seatunnel-connector-seatunnel-fake] Incorrect use ThreadLocalRandom

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
Error in class org.apache.seatunnel.connectors.seatunnel.fake.source.FakeSourceReader
    private final Random random = ThreadLocalRandom.current();

    public void pollNext(Collector<SeaTunnelRow> output) throws InterruptedException {
        // Generate a random number of rows to emit.
        int size = random.nextInt(10);
    }

int size = random.nextInt(10);
The variable size actually is a fixed value, not a random number,because can not share ThreadLocalRandom  in multi-thread.The correct usage is as follows:
int size = ThreadLocalRandom.current().nextInt(10);
SeaTunnel Version
api-draft 2.1.1-SNAPSHOT
SeaTunnel Config
FakeSource {
      result_table_name = "fake"
      field_name = "name,age"
    }

Running Command
run org.apache.seatunnel.example.flink.SeaTunnelApiExample

Error Exception
no

Flink or Spark Version
No response
Java or Scala Version
No response
Screenshots
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Close by #2060


How to use nyc with TypeScript and ESM?

Hi there, I moved my TypeScript codebase from CommonJS to ESM (using "type": "module" in my package.json file). My nyc.config.json looks like this:
{
  "all": false,
  "check-coverage": false,
  "exclude": ["**/*.d.ts", "**/*.test*.ts", "**/index.ts", "**/demo/**/*"],
  "extension": [".ts"],
  "include": ["src/**/*.ts"],
  "per-file": false,
  "reporter": ["text-summary"],
  "require": ["ts-node/esm"]
}

According to the docs of ts-node, I have to switch from --require ts-node/register to --loader ts-node/esm.
I tried to change "require": ["ts-node/esm"] to "loader": ["ts-node/esm"] in my nyc.config.json but I am getting this error:

Must use import to load ES Module

Can you help me with a code recipe to solve that? Currently I am starting my tests with Jasmine without nyc: ts-node-esm ./node_modules/.bin/jasmine --config=jasmine.json.
Best,
Benny

Today I learnt that c8 supports .nycrc.json config files, so I could easily switch to c8 and make it working with TypeScript, ESM & Jasmine:
{
  "scripts": {
    "test": "c8 --config=.nycrc.json ts-node-esm ./node_modules/.bin/jasmine --config=jasmine.json"
  }
}


Upgrade SpeziAccount

Upgrade SpeziAccount
:recycle: Current situation & Problem
There is an upcoming release of SpeziAccount that restructures and simplifies account setup procedure. Further, it adds a new Account Overview that allows you to view and edit your active account details.
For more information see:

https://github.com/StanfordSpezi/SpeziAccount/pull/7
https://github.com/StanfordSpezi/SpeziFirebase/pull/8

:gear: Release Notes

Upgrade to new SpeziAccount
Upgrade to new SpeziFirebase

:books: Documentation
TBA
:white_check_mark: Testing
TBA
:pencil: Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

[x] I agree to follow the Code of Conduct and Contributing Guidelines.

This is currently blocked by https://github.com/StanfordSpezi/SpeziOnboarding/issues/21

We still want to incorporate https://github.com/StanfordSpezi/SpeziAccount/pull/24


If statement

Hi, in my use case, we need to log into the app at first launch, then some other UI test happens. But on the second launch, the login screen doesn't show. In this situation we need an if statement to separate these two work flows.
# flow.yaml

appId: com.example.app
---
- launchApp
- if assertVisible : "Phone Number"
  then :
    - tapOn: "Phone Number"
    - inputText: "+123456789"
    - tapOn: "Confirm"
- elif OTHER_CONDITION
  then :
    - ...
- else :
   - tapOn: "Search"
   - ...
- fi

To support this particular use case Maestro offers an initFlow: https://docs.mobile.dev/reference/app-state-restoration
The idea is that you would extract your login flow into a separate file and refer to it in your actual test

That said, an if statement still has its own use cases and we will consider adding it

1 for this enhancement suggestion, it would be fairly critical in some areas

Adding a +1 here. we have a similar case where there is a flow (or a set of steps) we would like to run if an element is visible/invisible.
In my mind the ideal syntax would be (recalling similar syntax of the extendedWaitUntil):
- runFlow: open-rh.yml
  visible: Element
  notVisible: Element

but I guess the possibility to add elif and/or else would be interesting

I guess this use case is partially covered by https://github.com/mobile-dev-inc/maestro/pull/245 ? without the else

Nice find, looks like it's gone in to 1.10.x although nothing's been announced for it yet

This is indeed covered with the conditional runFlow execution