new event: LIVING PROOF SIMULCAST W/ BETH MOORE

@agarrharr please complete by Wed 8.1

Living Proof Simulcast with Beth Moore
Saturday, September 15
9am-4pm @ Lifestone Church
$25 includes event + lunch
Join Beth and thousands of women worldwide as she shares truth to guide your own journey of faith. You're invited to be part of this global, one-day simulcast that will encourage you to dive deeper into the Word of God. Beth follows the leading of the Holy Spirit to prepare a specific message for each of her events, and the simulcast is no exception. Don't miss out on this special event! Register today!
embed form:

I need to do #384 first in order to add this event, but that should be an easy fix.

Done.


Display two locations when no route was found

As a user I want the map to display and zoom to two locations even when no route was found in order to know which places I searched. I want to get an appropriate error message, that tells me why a route could'nt be found.
2

Actual: 1h


R.matchEq

Matching substrings isn't fun but i often have to parse such things in web development.
Typical code has to check for existence of a match before reading the contents.
If you do this a lot e.g. parsing url params, it looks really silly.
var string = 'abc=123&uvw';

// Do a check because R.match(/abc=(\d+)/)(string)[1] === '123' throws an error with string = 'abcd=123'
R.match(/abc=(\d+)/)(string) && R.match(/abc=(\d+)/)(string)[1] === '123') // true

R.matchEq would work like this
R.matchEq(/abc=(\d+)/, '123')(string) // true

// also with multiple groups
R.matchEq(/abc=(\d+)&(\w+)/, '123', 'xyz')(string) // false

An alternate version
R.matchCmp(/abc=(\d+)/, R.eq('123'))(string) // true

// also with multiple groups
R.matchCmp(/abc=(\d+)&(\w+)/, R.eq('123'), R.eq('xyz'))(string) // false

I'm don't think such a function has a wide enough appeal for the core, but here's a possible implementation, based on eqDeep in #718, which is not quite complete, but should be ready soon and will be included in the next release.
var matchEq = curry(function(regex, values, text) {
    return eqDeep(skip(1, match(regex, text) || []), values);
});

The API is slightly different from what you suggest:
matchEq(/abc=(\d+)/, ['123'], 'http://example.com?abc=123'); //=> true
matchEq(/abc=(\d+)/, ['123'], 'http://example.com?abc=pqr'); //=> false
matchEq(/abc=(\d+)/, ['123'], 'http://example.com?xyz=123'); //=> false
matchEq(/abc=(\d+)&(\w+)/, ['123', 'xyz'], 'http://example.com?abc=123&xyz'); //=> true

Of course it's curried, so you can write
var test = matchEq(/abc=(\d+)&(\w+)/);
var test123xyz = test(['123', 'xyz']);
test123xyz('http://example.com?abc=123&xyz'); //=> true
test123xyz('http://example.com?abc=123&pqr'); ==> false

and so forth.
Would this work for you?

Yes, awesomeness :grin:  :+1:


image busybox dns resolution failed

k8s: 1.17.2
os: centos 7.6
kernel: 3.10.0-1062.el7.x86_64
thanos: v0.10.1
prometheus headless service is not  resolution by thanos-query container.
but ping is work

I think the best place to ask is k8s community, it is a network issue indeed, which relates to your CNI and CNI config, even host iptables/firewall.

I think the best place to ask is k8s community, it is a network issue indeed, which relates to your CNI and CNI config, even host iptables/firewall.

others Pod container is work,only thanos


Warning message

Got the following warning message:

WARNING in ./~/phaser/build/custom/p2.js
Critical dependencies:
24:397-404 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
@ ./~/phaser/build/custom/p2.js 24:397-404

What could be wrong? Thanks

Hi. Nothing is wrong. The warning message is from webpack telling to us "hey this is a custom build".
You could use normally, the real problem is with the phaser packages, but not with the project itself


IDrawingContext.PushClip with Geometry.

We have to support something like this
var geometry = new CombinedGeometry();
geometry.Geometry1 = new RectangleGeometry(Utils.Convert(_clipStack.Peek()));
geometry.Geometry2 = new RectangleGeometry(Utils.Convert(rect));
geometry.GeometryCombineMode = GeometryCombineMode.Exclude;
_g.PushClip(geometry);
```csharp

Added by #544.


Design cleanup

Removed the dat-design dep, cleaned up messy styles, started to use tachyons.
This should help to make the transition to sheetify/base-elements easier and avoid breaking all the styles.

Nope it's fine, reserved keywords as property names were ok going ES5
onward iirc
On Tue, Nov 22, 2016, 13:01 Julian Gruber<EMAIL_ADDRESS>wrote:

@juliangruber commented on this pull request.
In pages/main.js https://github.com/datproject/dat-desktop/pull/89:

         click: () => send('app:open', dat)

       })}
       ${button({
         icon: 'link',
         text: '',

       klass: 'row-action',

       cls: 'row-action',

doesn't that mess with anything that tries to parse the source? class is
a reserved keyword
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/datproject/dat-desktop/pull/89, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlemiT-9RZ1YecCDnAJ2T43CTSDzR-ks5rAtmJgaJpZM4K5Ls2
.

Nope it's fine, reserved keywords as property names were ok going ES5
onward iirc

Oh, learned something :) Ok if this is only ever going to be used in Dat Desktop, I'm +1, otherwise we do need to worry about browsers and old node versions.

Oh yeah afaik this runs like IE7+ or something / all node versions haha -
like ES5 has been around for a while I think. I've never run into issues at
least (:
On Tue, Nov 22, 2016, 13:05 Julian Gruber<EMAIL_ADDRESS>wrote:

Nope it's fine, reserved keywords as property names were ok going ES5
onward iirc
Oh, learned something :) Ok if this is only ever going to be used in Dat
Desktop, I'm +1, otherwise we do need to worry about browsers and old node
versions.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/datproject/dat-desktop/pull/89#issuecomment-262224189,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlesxnKymCvXJ_YQ745zcwIX2fPAb-ks5rAtp8gaJpZM4K5Ls2
.

OK I fixed the merge conflict and cleaned up the unneeded main.css file


drop ruby 2.5 support

ruby 2.5 started failing in CI again, and I just don't have the energy to try to fix it.
https://github.com/sparklemotion/mechanize/actions/runs/4382526288/jobs/7741821736#step:3:346
It's time.

Note that I've updated the title and description to be: drop 2.5 support


Add optional buffered writer and direct flush

This allows users to both add a larger buffer if need be and also remove the buffer entirely (by calling flush after every write, sadly rust does not have any way to remove the buffer from stdout)

@JomerDev
It looks pretty good.
Did you tested it? I mean, does it worked for you before of it + After you added?
I'm wondering what's your use case with stdin, do you actually type or pass input in another way?
Thank you very much for your contribution!

Both have been tested, yes.
I didn't change stdin, I assume you mean stdout?
In my case I pipe the output of serust into defmt-print to properly format the message before printing it out, however without flushing the stdout defmt-print only receives anything when the buffer is full, meaning if you don't send many messages it looks like you're not receiving anything until suddenly a buffer full of messages appear

Thank you very much for your contribution :)


(PR) Style Edits for unFederal Reserve

Pull Request for unFederal Reserve
Etherscan: https://etherscan.io/address/0x5218e472cfcfe0b64a064f055b43b4cdc9efd3a6
CoinGecko: https://www.coingecko.com/en/coins/unfederalreserve
Website: https://app.unfederalreserve.com
Twitter: https://twitter.com/Unfederalreser1

Quick style edit in .scss for font color to address legibility.

There is a conflict in your PR, can you resolve it?

Requested conflict resolution done.


Rename enum exception

Update enum's exception to be consistent with ObjectIsNotClassError

Hi, thanks for contributing to Strawberry 🍓!
We noticed that this PR is missing a RELEASE.md file. We use that to automatically do releases here on GitHub and, most importantly, to PyPI!
So as soon as this PR is merged, a release will be made 🚀.
Here's an example of RELEASE.md:
Release type: patch

Description of the changes, ideally with some examples, if adding a new feature.

Release type can be one of patch, minor or major. We use semver, so make sure to pick the appropriate type. If in doubt feel free to ask :)
Here's the tweet text:
🆕 Release (next) is out! Thanks to Patrick Arminio for the PR 👏

Get it here 👉 https://github.com/strawberry-graphql/strawberry/releases/tag/(next)


Update to 1.11.5

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


we need a nicer way to show “empty” conversations.

This is a design request — we need a nicer way to show “empty” conversations.
Slack Message

This has been improved immensely so going to close this out


Define top level elements

After merging the other two PRs this one now has two conflicts. Can you please clean it up so it applies cleanly again? Thanks.

updated PR to remove conflicts, please re-review

LGTM, thanks.


Cow: Watch nextgclasses.com

Cow requests the watch of the watch_keyword nextgclasses\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Dragonrage in Charcoal HQ


Password check should be case insensitive

I was stuck on the login for a few attempts because I assumed it would be case insensitive. I think it would make it easier if it actually was case insensitive

I submitted a PR with more or less the same suggestion, but there have been some arguments against it :
https://github.com/gamer-os/steam-buddy/pull/74


golang https use custom certificate

Hello
How can I use my own certf and key ?

At the moment custom certificates are not supported out of the box.
This may be added eventually in the future since it was requested also in https://github.com/pocketbase/pocketbase/discussions/930 but for now is out of the scope for v1.
As a workaround you can put PocketBase behind a reverse-proxy (nginx/apache/caddy, etc.) and manage the custom certificate via certbot or other similar tool.
For an example nginx config you can check https://pocketbase.io/docs/going-to-production/#using-reverse-proxy.


[8.x] Retry connection if DNS resolution fails

Recently I've been investigating some connection failures:
SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name or service not known (SQL: select * from ...)

Upon investigation, I noticed that this happened about 36 times out of 130,396 requests in. Although extremely low (0.02%), it is still quite disruptive to have some requests throwing 500 Internal Server Error and writing database connection logs.
AWS Support has informed that due to transient network issues, it is possible that an extremely small number of connections to RDS or Elasticache might fail and that their engineers are always working on trying to reduce even further these errors. Since it's a rare event of connectivity issues, retrying the connection seem to be a viable option and doing this on my own project seems to be so much harder than using Laravel's built-in system for reconnection.

This should target the 6.x branch. :)

This should target the 6.x branch. :)

Yep, indeed. @deleugpn can you send this to 6.x?

Yep, indeed. @deleugpn can you send this to 6.x?


feat(frontend): Disable if amount higher than balance

Motivation
We want to give fast feedback to the user if a transaction can't be made.
In this PR, compare the amount that the user wants to send to the current balance and show an error is the amount is larger.
This doesn't consider the fee because the fee is calculated based on the amount, the utxos and the current fee of the network in the backend.
Changes

Introduce a customValidate in BtcSendAmount.

Tests
Tested locally.

@AntonioVentilii-DFINITY @peterpeterparker please review


Increase the interval for new table polling thread

Currently, the poller thread which continuously keeps checking for new tables checks every 5 seconds if there is a new table and restarts the connector based on that. However, this can cause instability in the connector if it detects new tables very frequently and causes too many connector restarts at shorter intervals.
The solution is to increase the polling interval and provide a configuration to configure it as well.

Closing as the issue has been addressed and the relevant PR has been merged.


Feature request: Automatic BAM-to-CRAM conversion

Can we add an option to convert BAM output files into CRAM automatically? BAM-to-CRAM conversion is already supported in bcbio (see cram.py), but as far as I can tell there's no way to set this to run automatically for the RNA-seq pipeline.

Heya, we probably won't implement this unless more people ask for it. Can you just do it downstream?

Ah OK, I'm seeing that this is supported as a post-processing step.
From the run_info-bam.yaml unit test, for example:
# `cram` or `cram-lossless`
details:
  - algorithm:
      archive: cram-lossless

Hey @roryk yeah I can run it downstream, I was just wondering if it's easy to config directly in the bcbio YAML.

I see, have you tried setting that option and seeing if it saves the BAM files that way?

I haven't yet but I'm going to be reprocessing some old RNA-seq data next week and can give it a shot. I'll try to post an update here.

Heya-- did this end up working?

@roryk Haven't had a chance to work on this yet but I'll keep it on my todo list

Hi,
I can confirm the archive option works, we use it on the daily without any issues.
Cheers
M

Hi @matthdsm,
Thank you for answering! The best kind of feature request: one that is already implemented.

Nice thanks @matthdsm ! I'll try that out


Debug TransactionProcessor performance

Similar to #3246 (with #3224) I realized that TransactionProcessor is slower than it should be:

Compared to OperationProcessor (yellow line), which inserts much more rows, it can be 3x slower. We should debug it and understand where is the bottleneck.

Accidentally closed in https://github.com/stellar/go/pull/3257 that should close https://github.com/stellar/go/issues/3238. Reopening.

The slowness is connected to marshaling and then encoding to base64 of some transaction related XDR objects. Nothing can be done here except making XDR encoder faster which is already tracked in https://github.com/stellar/go/issues/2689.


Fix changing blank nodes

Due to changes in an upstream API, blank nodes were formatted differently causing their content to change  in the inferencing process. This PR resolves that issue.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


nixos: wpa_supplicant: warn on unused config

Motivation for this change
After https://github.com/NixOS/nixpkgs/commit/71ea6a9a41f1340e6821812f8b7e331072dbd020 there are additional cases, where wpa_supplicant uses an auto-generated config.
Because it can't use multiple config files, and the config format doesn't permit includes, that will silently ignore a present /etc/wpa_supplicant.conf. There are valid reasons for keeping that file outside of extraConfig, because it may contain secrets.
This is intended to avoid silently breaking people's config in 20.09
see https://github.com/NixOS/nixpkgs/issues/59959#issuecomment-678681134
Things done
Implemented a run-time warning, that will detect a condition of /etc/wpa_supplicant.conf being present, but ignored in favor of a a generated config file.

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

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

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

cc @bobismijnnaam

I assume the echo in script ends up in one of systemd's logs? (I'm not very well acquainted with systemd)

I assume the echo in script ends up in one of systemd's logs? (I'm not very well acquainted with systemd)

Yep, and the <3> marks it as error priority.


Drop Pointer Events Extensions from spec list

Removed in https://github.com/w3c/pointerevents/pull/310.

I've also sent https://github.com/tidoust/reffy-reports/pull/43.


Roll engine 520746ed9c6b..b10b8e899029 (1 commits)

https://github.com/flutter/engine/compare/520746ed9c6b...b10b8e899029
git log 520746ed9c6b..b10b8e899029 --no-merges --oneline
b10b8e899 Roll src/third_party/skia 1e00aebd9a45..b45b53f01cf3 (3 commits) (flutter/engine#6852)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

Auto-roller completed checks. About to merge.


Question: This plugin changes the way fold happens in markdown (or it cosmetic) ?

hi, the biggest drawback of using markdown in neovim for me is the fold, i set up the fold method in treesitter as recommended, but many times fold do mistakes like folding two heading with the same level, fold the entire list instead of just subitem (with nested bullets). So this plugin would solve these wrong behaviours ?

Folding is handled by tree-sitter.

[!NOTE]
There are quite a few bugs with the markdown & markdown_inline parser.
So, expect bugs. The parsers can become a bit unreliable when using nested list items, tables or any sufficiently complex syntax.

You can create ~/.config/nvim/queries/markdown/folds.scm and add the folding rules there.

[!TIP]
Use :tabnew $VIMRUNTIME/queries/markdown/folds.scm to see the default value.

So this plugin would solve these wrong behaviours ?

The problem is it's hard to know what people consider default behavior. I don't want to change the folding logics as it may be something unexpected for normal users.


Quilt Loader impacts

TL;DR: Fabulously Optimized will not move to Quilt soon, but it is something that has to be considered long-term if it becomes widespread. If you want to vote for something, here you go: https://curseforge-ideas.overwolf.com/ideas/CF-I-2662

Here is a FAQ of why Quilt matters to Fabulously Optimized, and what has to be done to accommodate it.
What is Quilt?
The site describes it as

The Quilt project is an open-source, community-driven modding toolchain designed primarily for Minecraft. By focusing on speed, ease of use and modularity, Quilt aims to provide a sleek and modern modding toolchain with an open ecosystem.

...but it is essentially a fork of Fabric Loader and API because of conflicts within its management team.
Why does it matter?
Because some current Fabric mod devs are planning to move over to it, dropping support for Fabric altogether. And others, well, aren't. Who knows, how many mods will be affected in the long term.
When does it matter?
Possibly when more launchers and Curseforge supports it.
The first beta released on 2022-04-20 and Modrinth had the mod listing support from the start. Then some launchers followed, and... will see.
Can Quilt load Fabric mods?

In most cases, yes. As Quilt is a fork, most Fabric mods should be compatible with Quilt initially – but this may not be the case forever.

Can Fabric load Quilt mods?

No. Quilt mods are distinct from Fabric mods, and not defined in the same way.

Can I install Fabulously Optimized and replace Fabric with Quilt now?
Probably, while Fabric mods are still supported in it, but do not ask for support regarding that.
How long will backwards compatibility for loading Fabric mods last?

Quilt will likely continue to support Fabric mods directly for quite some time – at least until Quilt is properly established. However, at that point, we do plan on dropping first-party support for Fabric mods – although, there’s no reason the community can’t continue to maintain that support, and we’ll provide the required resources if someone else decides to continue that part of the project after we stop maintaining it.

So what if Fabulously Optimized wants to move to Quilt?

First and foremost, (widespread) launcher support is needed
Hosting is needed (Curseforge - vote, Modrinth - exists)
Enough mods moved over to be worthwhile
~The mod list issue needs to be resolved (probably with a separate mod)~ Seems like this won't be an issue.

The mod list issue?
Edit: read this comment for an update

~Quilt, similar to Forge, is using a system where a list of all used mods must be sent to the server. That means the server can see all mods you use and disallow you if you are not using the mods server allows (regardless of whether the mods you use provide the same features or not).~
~Fabulously Optimized deems that as an invasion of users' privacy and freedom.
No one should be banned because they use "too many mods" or "not the right zoom mod". The servers can already ban any cheaters or rule disobeyers with existing, heuristical plugins, they do not need to see the names of the client mods for that (nor do the cheat mods announce themselves anyway).
Quilt has said there will be no configuration or opt-out for that system, so one must hope there will be an external mod that can opt this out.~

So what if Fabulously Optimized will stay on Fabric?

Short-term, nothing will happen
Long term, the list of available mods may decrease drastically and Quilt would have to be considered to keep up with it. If done, efforts will be made to make the transition as seamless as possible to users.

What about both?
Maintaining two modpacks is too much for me.

Sources:

https://quiltmc.org/about/faq/
https://quiltmc.org/about/faq/developers/
https://discord.quiltmc.org/

Replying this as it seems relevant to my personal needs:

The privacy context is the top priority and that i do not wish for everyone to be affected by a blocking-wall in a sense that for example being that you are only allowed to use sodium instead of optifabric / canvas renderer due to the server owner choosing this type of path instead of letting the user decide on what they want to use in this respect,

and while i do recognize that this would reduce cheaters to a minimium - this would in turn cause server owners/quilt developers have to whitelist/blacklist multiple mods in hopes this would be effective which...unfortunately isn't. it would in fact make things worse for novice/experienced modders as they must obey on what the server owners want people to use. (malicious or not)

The compatibility mode is helpful so that mod developers have more time to decide on rather they wanna make the jump to quilt in it's entirety or not as it is considered fair similar to forge -> fabric jumping. Although i am not sure on how many developers are considering this as some of them haven't seen this yet or just aren't ready for it due to burnouts and all that - but i assume documentations could help this a bit but who knows?

I am looking forward to the beta obviously. although with the two things i have discussed along with madis; this would be considered questionable in some ways as i cannot be sure on how well the migration will turn out - even if i decline it; i just cannot guarantee the final result(s) of it.

Privacy issues can be easily resolved by adding a mod that would make the client look like vanilla

Privacy issues can be easily resolved by adding a mod that would make the client look like vanilla. Wurst already has this as a module, but not standalone + it would create the same concerns as their zoom mod.

Well the main problem with this is that people can still figure out what your client regardless of brand name so this won't change anything - it needs a more prior approach when trying to reduce exposure.

Privacy issues can be easily resolved by adding a mod that would make the client look like vanilla. Wurst already has this as a module, but not standalone + it would create the same concerns as their zoom mod.

Well the main problem with this is that people can still figure out what your client is regardless of brand name so this won't change anything - it needs a more prior approach when trying to reduce exposure.

The problem isn't that they see you using quilt (I think) but as long as you can make sure the server doesn't see all your mods by having a mod it seems like a good solution.

Just want to add something quickly here, the modlist sending will not be in the loader, it will be in the qsl networking module and i highly doubt any mods in FO right now use the networking module from at least fabric

As a quilt dev... I Just want to add something quickly here about the common assumptions about the modlist sending in quilt, it will not be in the loader, it will be in the qsl networking module and i highly doubt any mods in FO right now use the networking module from at least fabric.

Alright, but if any single mod uses that, the module still sends the entire modlist, right?

As a quilt dev... I Just want to add something quickly here about the common assumptions about the modlist sending in quilt, it will not be in the loader, it will be in the qsl networking module and i highly doubt any mods in FO right now use the networking module from at least fabric.

Alright, but if any single mod uses that, the module still sends the entire modlist, right?

Yes.

Instead of just adding reactions to my comment i think it would be better for you to actually join the quilt discord so you can find out more since github issues is not a good place to explain this

Also you will be fully able to patch this out

Fabulously Optimized deems that as an invasion of users' privacy and freedom. No one should be banned because they use "too many mods" or "not the right zoom mod". The servers can already ban any cheaters or rule disobeyers with existing, heuristical plugins, they do not need to see the names of the client mods for that (nor do the cheat mods announce themselves anyway). Quilt has said there will be no configuration or opt-out for that system, so one must hope there will be an external mod that can opt this out.

This isn't meant to be a anticheat, also if the server doesn't allow you to use like a zoom mod for a example just don't play on that server

Also this might be a bit off topic forge does this exact same thing and no body seems to care about that

Instead of just adding reactions to my comment i think it would be better for you to actually join the quilt discord to have a good ol' chat since github issues is not a good place to explain this, https://discord.quiltmc.org/.

I did it last year, it initiated a long discussion: https://discord.com/channels/817576132726620200/847158608524345394/857245880466145280
The result was: https://discord.com/channels/817576132726620200/847158608524345394/857601674167975966
Feel free to ping me there if you want to add anything to that discussion.

Also this might be a bit off topic, but forge does this exact same thing and no body seems to care about that

[sarcasm]
Indeed I don't care about that as

I no longer use Forge
I do not make a Forge modpack
I do not play on servers that do this

[/sarcasm]
...but that's not the point. People want an alternative to Optifine and I provide that.
I do my best to choose the best mods but I know that if someone would get a feature nerfed on a server (or maybe the server not liking the mod list altogether), they will want to or be forced to return to said Optifine. And that behavior is unhealthy for the entire modding community - getting blamed just because you're using the wrong thing, not because you broke any rules with that thing.

Hello! Quilt community manager here.
I just woke up so this may not be the most fantastic of responses, apologies.
The mod list packet is not designed to be an anti-cheat solution. Quilt will not be providing any mechanism to filter users based on it, nor will it be taking steps to make it difficult to patch out. As mentioned earlier, it will be part of the QSL networking module and, as it's a standard plugin channel packet, will require the server to be listening for it before sending anything.
The main reason the packet exists is to ease moderation in Quilt community spaces where the intention of a mod developer is ambiguous. It was a response to the long-winded issue about how to define cheat/utility mods - for grey-area mods, this will give us a yardstick to figure out whether the mod developer intends for their mod to be used on servers that do not want their mod to be used there.
Most of us completely agree that this isn't an ideal solution, and we'd love to get some suggestions on better approaches. That said, it's been an awful long time now, and we haven't really seen anything reasonable other than "screw what you need, remove it". Ultimately, we accept that some servers do not have competent or reasonable staff members, and that is the main drawback - but I also personally believe this is possible to mitigate with a good community solution to blacklisting categories of mods, rather than forcing server owners to do it themselves (although, as mentioned before, Quilt as an org will not be providing ways to action these packets).
Essentially:

The mod-list packet is not anti-cheat, is deliberately not designed to be resilient enough to be used as anti-cheat, and largely exists to help our moderators resolve grey area mod reviews in official Quilt spaces only
Yes, the approach has undeniable drawbacks. Got something better? I'd love to hear it.
I personally don't feel this is as large an issue as some people make it out to be - even though it is undeniably an issue, I believe we can get pretty far by educating server owners, and working with the community to come up with a good tool for category-based filtering that doesn't encourage server owners to inspect users' mod lists
If you're not developing a mod that could be considered cheating by conventional standards, we likely won't think to check for a patch - but we'd like to stress that including one makes it much easier for malicious mods to work around server restrictions

I think that's about all for now - I am unlikely to reply to this issue for a while since I have a pile of stuff to do before the beta on the 20th, but I do appreciate people's concerns here and would love to see a better solution to this problem post-beta. Feel free to hit me up on Discord if needed.

@gdude2002 Thanks for the reply.
In my opinion, a reasonable solution would be to broadcast only the mods that use said networking API instead of all mods the client has. Because obviously the server needs to communicate with the mods that network and this would preserve the privacy of mods that do not network at all or use a different method (like a different API).

@gdude2002 Thanks for the reply. In my opinion, a reasonable solution would be to broadcast only the mods that use said networking API instead of all mods the client has. Because obviously the server needs to communicate with the mods that network and this would preserve the privacy of mods that do not network at all or use a different method (like a different API).

That's an interesting solution - how would you go about denoting this?

Perhaps the API could provide a listener and all mods that register on it get their list sent at once?

Doesn't that just make it opt-in? Kinda defeats the point

It doesn't really help against "grey-area" mods either.
A common pattern in 1.8 cheats was to co-opt a well known "good" mod (say, keypress or cps mods) and then patch it with cheat functionality and distribute that.
This system (like Forge's) is completely ineffective to that.

Hmm no, I meant like if they want to use the abilities of the API, they must notify the API of their presence first and then the API records that and provides the methods.
Like instantiating a class, though that's a bit different concept.

I feel like this wouldn't work out for a number of reasons:

It'd make the API surface incompatible and generally worse
Most of the grey-area mods I'm thinking of wouldn't be using the networking API in the first place

Either way, probs better to have this discussion in a Quilt space - I'm not a Quilt dev (the Community Team is completely separate) and I doubt most of the devs are aware of this thread

It doesn't really help against "grey-area" mods either.
A common pattern in 1.8 cheats was to co-opt a well known "good" mod (say, keypress or cps mods) and then patch it with cheat functionality and distribute that. This system (like Forge's) is completely ineffective to that.

This isn't an anti-cheat! This is about moderation issues in Quilt spaces. I've said that a couple times.

@gdude2002

Either way, probs better to have this discussion in a Quilt space - I'm not a Quilt dev (the Community Team is completely separate) and I doubt most of the devs are aware of this thread

Could you refer to the most appropriate place for this discussion (e.g. specific thread in Quilt's discord)?
Don't really want to post in the wrong place and get an answer "this has been discussed already".

Probably the best thing to do is make a thread on the toolchain server entitled "modid list alternatives" or something like that

https://github.com/PolyMC/PolyMC/issues/406

We've confirmed support in both ATLauncher and PolyMC so far, yes.

@gdude2002 Thanks for the reply. In my opinion, a reasonable solution would be to broadcast only the mods that use said networking API instead of all mods the client has. Because obviously the server needs to communicate with the mods that network and this would preserve the privacy of mods that do not network at all or use a different method (like a different API).

Spoiler alert, this is standard Vanilla protocol...
At the time it was called Plugin Channel, but the idea is every custom packets that are defined there have an identifier, meaning that if a mod uses the networking API for a packet you'll have a channel with the mod id as the namespace.

@LambdAurora

Spoiler alert, this is standard Vanilla protocol... At the time it was called Plugin Channel, but the idea is every custom packets that are defined there have an identifier, meaning that if a mod uses the networking API for a packet you'll have a channel with the mod id as the namespace.

So why won't Quilt use it? Or maybe I'm misunderstanding your point.

I think the point was that your solution isn't really any better than what vanilla already offers - the idea exists because that wasn't enough on its own.

I don't understand why quilt has to add that if fabric can work without it.

Considering it was about moderation concerns and Fabric has minimal moderation at best, that's not really much of a statement haha

Moderation ? Didn't you sayed that the mod list wasn't to do anti-cheats ?

I fully explained this above, and yes, I did indeed say that. Please take another read, I'm not explaining it twice in the same issue.

I figured I'd update this issue with a few new data points now that Quilt is in beta.

The mod list packet has not yet been implemented - I've said for a while that I'd like to see alternatives, and we have plenty of time to find one stilk
We're planning on supporting Fabric mods for as long as possible - if it gets to a point where the maintenance work becomes detrimental to Quilt, we'll work with the community to find and support third party maintainers

Quilt has said there will be no configuration or opt-out for that system, so one must hope there will be an external mod that can opt this out.

Hi, QSL Core dev here. The main problem is with individual mods opting out of being part of the mod sync list, not users being unable to disable it entirely. I can't speak officially for the approach the team will decide on, but it is extremely unlikely that we will not provide some way to disable it fully, if it is the solution we go for.
It is up to the server you are connecting to whether or not to accept users with the mod list syncing disabled--same as Forge servers today.

There are now talks that the modlist idea may be scrapped as the feature flags could be sufficient for Quilt moderation purposes. As the RFC has not been merged, no final decision has been made yet.
Simplest way to explain feature flags is that the mod defines points of communication and if the server sends specific data, it changes the settings appropriately on the client. For example, a minimap that has points to disable radar and caves and respects the options when the server requests it to.
I'd say that is a fair approach and it is already being used in various mod loaders for a while, as it's something both the client and server have to opt into.

If the server requests a config change and client doesn't have that mod, nothing happens.
If the client has a mod that supports server-side config changes and the server doesn't send any, nothing happens.
If the client uses a specific mod and the server requests a change from that specific mod, the mod changes its config appropriately.

Sources (long conversations):

Thread (via)
Main chat (via)

Curseforge supports marking mods as Quilt now. Didn't yet check if the modpacks in their launcher are supported as well.

The tweet points out that there's no launcher support yet - they're still figuring that out.

From SpyglassMC/Spyglass#957:

@osfanbuff63 Quilt when reaching full release will have full support for Fabric mods. The point of [eventually] porting the mod is to support & utilize the more healthy ecosystem. ie. You would be able to use all of your Fabric mods alongside before they are ported.

https://www.curseforge.com/minecraft/mc-mods/jumpquilt is now a thing, for what it's worth.

Oh hey Logan, been a while since I've seen you around.
I think the best way to come to an opinion is via your own experience, personally. While it's impossible to deny (in good faith) that what happened at Fabric happened, it's worth noting that Quilt doesn't define itself as "an opponent", rather that it tries to be an improvement by serving as the final nuclear option that nobody really wanted to take.
Why not hang out on Discord and see for yourself whether you're a fan of the concept or not?

If I understand correctly you transitioned to the Quilt spaces which I am
very explicitly not a part of. Though with that said I've also been
inactive Fabric-wise for the past year or so.

Indeed I did, I'm a Community Manager there now - I was headhunted by the
initial planning group a few months in, though not before being banned from
Fabric spaces for something someone else did and that I wasn't involved in
(along with at least one other who were similarly uninvolved). I am on
around 180 Discord servers though, so I tend to see modders all over the
place.
While ultimately people's reasons for moving to Quilt are of course
personal and their own, calling Quilt a major overreaction ignores the
months of issues that affected the LGBT community (and to some extend the
plural community) members that were using Fabric's spaces at the time, as
well as the blatant disregard of the meaning of "community project",
something Fabric still (dishonestly in my opinion) uses to describe itself.
Indeed, some of the issues people have complained about continue to happen

for example, users being banned from Fabric faces for "spreading hostile
propaganda" on reddit, when in reality they've been posting logs of the
now-hidden meta channel that other people sent them as explainer of what
happened.

Anyway, super appreciate you being honest, and I hope your first steps as a
plural system go well - Quilt is extremely supportive of both LGBT people
and plural systems, and there's a lot of people (systems and not) there
that would be happy to help you out if you need support!
On Thu 4 Aug 2022, 14:19 LoganDark, @.***> wrote:

Oh hey Logan, been a while since I've seen you around.
If I understand correctly you transitioned to the Quilt spaces which I am
very explicitly not a part of. Though with that said I've also been
inactive Fabric-wise for the past year or so.
I think the best way to come to an opinion is via your own experience,
personally.
I am very biased and have an incomplete view of the situation so please
take all this with a grain of salt:

I wasn't there for what happened at Fabric
I don't see anything wrong with Player or how they treated the
situation following the incident (but, again, difficult to find neutral
sources on that)
I think Quilt was a major overreaction and Fabric is still very
technically impressive regardless of blips in the community spaces
I think Quilt's efforts to diverge and create incompatibilities with
Fabric could have been avoided
I think it's too late to go back now

Why not hang out on Discord and see for yourself whether you're a fan of
the concept or not?
It's difficult for me to justify that. I've never had any issues with the
official Fabric community spaces. Plus there's personal stuff
https://morethanone.info happening right now that means I won't be on
Discord until September 12th.
I know this isn't the place to discuss all the Quilt drama but I just
thought I'd give you a little more insight.
—
Reply to this email directly, view it on GitHub
https://github.com/Fabulously-Optimized/fabulously-optimized/issues/257#issuecomment-1205247043,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABR26NE2KRLEZPYYTVJMSDVXO7OJANCNFSM5QQASYLQ
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

your first steps as a plural system

Slight correction: I've been this way for over 3 years now, it's just that someone only sent the link to that website a few weeks ago, so I had no idea what it was called or that it was supposedly not too uncommon. That's why I link it whenever it's at all possible to do so; it's an important resource for people to know about. :)

Oh cool, sounds like you're finding your way now either way though!
I agree, it's a fantastic resource, I'd also recommend familiarising
yourself with PluralKit when you return to Discord if you haven't already -
it's been invaluable for the systems at Quilt. You probably knew about it
already though, haha
Anyway this isn't really the place for this chat I guess - feel free to hit
me up on twitter or discord if you feel like it, and I hope things go well
\o/
On Thu 4 Aug 2022, 14:40 LoganDark, @.***> wrote:

your first steps as a plural system
Slight correction: I've been this way for over 3 years now, it's just that
someone only sent the link to that website a few weeks ago, so I had no
idea what it was called or that it was supposedly not too uncommon. That's
why I link it whenever it's at all possible to do so; it's an important
resource for people to know about. :)
—
Reply to this email directly, view it on GitHub
https://github.com/Fabulously-Optimized/fabulously-optimized/issues/257#issuecomment-1205274040,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABR26P3RCK6XFPQA2W6NSTVXPB57ANCNFSM5QQASYLQ
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

If one day you decide to drop Fabric support altogether you will be leaving a lot of people behind.

This outcome doesn't follow from what you wrote. As long as launchers support Quilt, and as long as all the existing mods work on Quilt, nobody will be left behind, because everyone installing the modpack will still be able to use it.
User preferences between Quilt and Fabric have little to no bearing here because using Quilt or Fabric is just an implementation detail of the modpack af the end of the day.

This outcome doesn't follow from what you wrote. As long as launchers support Quilt, and as long as all the existing mods work on Quilt, nobody will be left behind, because everyone installing the modpack will still be able to use it.

It's not because of technical limitations that I said that. There are users who do not use Quilt for other reasons, like myself. Those are the people who would get left behind by such a migration.

I don't think there's evidence to conclude that these users make up a meaningful proportion of FO's userbase or contributors, so I don't think project decision making should be constrained by them.
The decision of whether to use Fabric or Quilt for FO should be done based on the relative technical merits of both, since those are what ultimately impact the user experience. While Fabric seems to be the better option currently, it's likely that Quilt will be a better option as it matures and gains support from all popular launchers, hence the creation of this issue.

Coderbot said it well, and just to reiterate that this is the official stance, I'll repeat:
I am interested in moving over to Quilt only when it is technically the only feasible way forward, aka only when most (or most important) mods do it. I do not want to do it for "community reasons" for either loader, because ultimately I view both as just tools.

LambdaBetterGrass has moved over to Quilt in the 1.19.3 update since it was infeasible to port the mod to 1.19.3 without utilizing the APIs that Quilt provides related to resource reloading. As a result, I think it's worth evaluating whether a move to a Quilt-based modpack that uses JumpQuilt on CurseForge is worthwhile.
In my experience, the original JumpLoader (for Fabric) only really caused one big issue, which was a resource loading bug that was caused by fragile code I originally wrote for Fabric API. Needless to say, that problem wouldn't be relevant for JumpQuilt, so I think it would be worth doing a feasibility test of FO on Quilt rather than potentially wasting time replacing or porting a dependency that already exists, which is the only other option.

LambdaBetterGrass has moved over to Quilt in the 1.19.3 update since it was infeasible to port the mod to 1.19.3 without utilizing the APIs that Quilt provides related to resource reloading. As a result, I think it's now worth evaluating whether a move to a Quilt-based modpack that uses JumpQuilt on CurseForge is worthwhile.
In my experience, the original JumpLoader (for Fabric) only really caused one big issue, which was a resource loading bug that was caused by fragile code I originally wrote for Fabric API. Needless to say, that problem wouldn't be relevant for JumpQuilt, so I think it would be worth doing a feasibility test of FO on Quilt rather than potentially wasting time replacing or porting a dependency that already exists, which is the only other option.

I am currently still having a "wait-and-see" approach.

As of now, that is just a one mod. Maybe it will be two when LambDynamicLights moves over, but that would still be insignificant on a grand scale. I'm not seeing a mass exodus by performance or graphical mods just yet.
As of now, being easier to port to did not actually mean it would be faster to actually do so. Still took two months to get it on 1.19.3. Note that I'm not blaming the dev or Mojang for anything, just stating the current state of things. Maybe there will be a bigger speed difference for 1.19.4/1.20/1.20.1 mods?
Currently the UX of using Quilt is still suboptimal. JumpQuilt is needed for CurseForge and GDLauncher; CurseForge shows 6x less mods and Modrinth 3x less mods as compatible with Quilt compared to Fabric (regardless of what is the real case).
There are now and may be some Quilt-specific bugs that occur when running Fabric mods. May be insignificant, but it is also a point to consider.

Maybe I'll consider it for 1.21 if the situation changes by then.

The problem is that this approach leads to a circular outcome. There's not many quilt exclusive mods because platforms, modpacks, and other mods aren't quilt exclusive, and platforms and modpacks don't switch to quilt since there's not many quilt exclusive mods. So just keep that in mind when you directly work around Quilt mods as they start to move over, as it seems is happening with better grass.

I am not saying that Quilt should have more exclusive mods, in fact any kind of exclusivity is actually bad for the user.
What I'm saying is a natural progression of how Quilt could replace (or "replace") Fabric:

First-class support by loaders and listings (if your mod supports Quilt, mark it as such!)
Few devs that find Quilt tools as beneficial (performance/graphical mods) will move over
Modpacks will see that Quilt is worth switching to
Users will see that Quilt is worth switching to
Mod devs will see that Quilt is worth developing to (whether exclusively or not is case-by-case)

In an ideal scenario, most mods will keep working on Fabric and Quilt as they won't use Quilt internals. But those that do could drive the force for the entire ecosystem, if they themselves are significant in it.

As of now, being easier to port to did not actually mean it would be faster to actually do so. Still took two months to get it on 1.19.3. Note that I'm not blaming the dev or Mojang for anything, just stating the current state of things. Maybe there will be a bigger speed difference for 1.19.4/1.20/1.20.1 mods?

It took me two months because I shockingly have a uni life to attend.
1.19.3 wrecked atlases, model loading, and resource loader.
Which are things LambdaBetterGrass heavily depend on. It would have taken me longer to port anything if I chose to stay on Fabric. Quilt provides me with the abstractions I need to work with virtual resource packs and with great integration within the game (this is good for both devs and users). I chose to not reinvent the (my own) wheel.
This also guarantees faster updates in the future even though it was not that visible in 1.19.3.

Currently the UX of using Quilt is still suboptimal. JumpQuilt is needed for CurseForge (please vote) and GDLauncher (to be implemented in their rewrite)

As far as I know it's a false issue, people had no issues working with JumpLoader for Fabric stuff back in the days. It also means stuff works despite the lack of support from CurseForge.

I am not saying that Quilt should have more exclusive mods, in fact any kind of exclusivity is actually bad for the user.

Depends on the case! In this case the LBG exclusivity is kind of good: some intended behavior was broken due to lack of support on Fabric. For example LBG's built-in default resource pack is intended to be enabled by default upon pack discovery if the pack was never seen before, this is not supported by Fabric but by Quilt. The mod also has now better support for resource loading features. Any optimization made on the abstraction will actually be applied to the mod as well and be good to the user. (And Quilt resource loader actually implements some optimization measures).
I'm getting a bit tired about the "exclusivity" debacle, it's not like Fabric which was incompatible with Forge mods, Quilt has compatibility with Fabric mods making the exclusivity argument kind of useless.
Sure some mods don't work with Quilt but they're a minority, and usually have weird stuff associated to them, which would have broke in another context too at one point.

IMPORTANT: this is not the official view on Quilt from FO, this is my personal opinion only.

It's also worth noting that Iris is about to move to Quilt-recommended (but not required) and their installer will be installing Quilt instead of Fabric.
Personally, I'm not against moving to Quilt, but it's quite a big change to make, with the CF debacle being the biggest issue, but we can all blame CurseForge for that one... Anyway, I for sure think it's more worth consideration than it was back in August of last year, when no one had moved in the first place. We're getting to the point where there are more and more mods moving over or recommending using Quilt.

...has alternatives to mods that moved to Quilt-only

Another reminder that this is just a big loop as well. coderbot put it well to revive this conversation:

The problem is that this approach leads to a circular outcome. There's not many quilt exclusive mods because platforms, modpacks, and other mods aren't quilt exclusive, and platforms and modpacks don't support quilt since there's not many quilt exclusive mods.

Besides supporting modders, I can't understand from the bit that I've used CF Launcher how it's better than any other, since we all know the bloat/slowdown Electron is (and the fact, it's the only currently closed-source launcher we support (iirc GDLauncher is following suit though), and the UX is honestly not any better because it takes up so much screen space that it doesn't need. IIRC Modrinth is working on a way to pay modders for launcher-based downloads (source: modrinth/knossos#783. Anyway, that's a mostly unrelated comment but /shrug

We're June, and now I've seen the pretty disappointing treatment of mods that dare go Quilt only.
Rather than to look into JumpQuilt, which pre-Fabric supported modpacks did not have any issue to use its predecessor, I see a will to recreate, feature-incomplete versions of the mod to replace them in the pack.
So, I'd like to put back on the table a reconsideration of the current treatment of Quilt, especially that now QSL and Quilted Fabric API have finally a stable versioning since we consider the libraries to be stable enough.

We're June, and now I've seen the pretty disappointing treatment of mods that dare go Quilt only.
Rather than to look into JumpQuilt, which pre-Fabric supported modpacks did not have any issue to use its predecessor, I see a will to recreate, feature-incomplete versions of the mod to replace them in the pack.

I'd say you're looking at it from a wrong angle, which I'd draw a parallel to the new, currently more relevant event #626. Just because some mods are "jumping ship" does not mean there is yet a critical mass doing it.
I'll not switch to Quilt just because some mods switched over - for now that just means a minor inconvenience and a void to fill.
But as with the aforementioned event, it already means that a migration strategy could be made, and a chance to make some changes on my behalf for a better future (https://github.com/Fabulously-Optimized/fabulously-optimized/issues/627).
I have considered accommodating Quilt by doing something like providing an overrides file similar to my Fabric one, though for the time being I don't really understand the syntax described there and didn't fully test it yet as it seemed to lack a feature or two I'm currently using.

Here's a summary of what I currently think of Quilt:

CurseForge support of Quilt is there but still sucks. JumpQuilt is a thing but using it would not be an upgrade to users in terms of UX. CurseForge still has the majority (~60%+) of downloads for FO so this will not be ignored.
Adding mods to the pack is currently painful on all launchers - CF would suggest Forge mods and others would suggest a subset of Fabric mods. Solution would be to ask more devs to mark their mods as Quilt-compatible.
Quilt lacks Fabric-like overrides which benefit FO a lot in logs and alphas-betas. As the syntax is different, I am not sure it can work the same as the Fabric file yet.
Quilt overall has less development at the moment, which may affect bugs and version updates and does not instill confidence of sustainability, neither does this event. More time is needed to see how things go.

Here is a summary of what I'm currently doing:

FO for 1.20.1
#626 which is currently a much more relevant issue than Quilt
#627 and #110 to make vanilla support more user-friendly and sustainable for me
#596, for which I have some interesting plans which you'll see when done

Here's what you can do:

Keep voting and bugging CurseForge on better Quilt support.
Ask all your favorite mods to mark theirselves as explicitly Quilt-compatible
Help Quilt with development. FO could bring more users to Quilt, but if there are not enough developers, what's the point...

 JumpQuilt is a thing but using it would not be an upgrade to users in terms of UX. CurseForge still has the majority (~60%+) of downloads for FO so this will not be ignored.

Overall I am definitely blaming CurseForge a lot more, everything feels like an uphill battle with them, except maybe when it comes to malware.

Adding mods to the pack is currently painful on all launchers - CF would suggest Forge mods and others would suggest a subset of Fabric mods. Solution would be to ask more devs to mark their mods as Quilt-compatible.

I have not noticed that many Fabric mods not marking their mods as Quilt-compatible, but I guess that might be user-bias. In the Quilt Project Discord every linked mod updates or releases are asked to at least mark their releases as Quilt-compatible because then why advertise there?

Quilt lacks Fabric-like overrides which benefit FO a lot in logs and alphas-betas. As the syntax is different, I am not sure it can work the same as the Fabric file yet.

I believe that Quilt has now Fabric-like overrides with equivalent features despite the different syntax.

Quilt overall has less development at the moment, which may affect bugs and version updates and does not instill confidence of sustainability, [...]

So far, despite slower pace at the moment, there wasn't any critical issue affecting bugs or version updates.

[...], neither does this event. More time is needed to see how things go.

That's kind of a shit argument here, during that event the development did not care about kashike's tantrum and continued to work, as said in the statement, and as this GitHub PR comment testifies.
About #626, from what I read on the issue it seems to be a solved question since the modpack now bundles those mods? I'm not sure how it's more relevant if it's solved.
And I will reiterate, what I find extremely disappointing is how easy it has been to replace one of the mods with a low quality resource pack the minute it jumped to Quilt. No discussion with the mod author. The thing to learn with that is, as a mod author, I can't expect support from one of the de-facto OptiFine alternatives modpack. Now if I have users complaining about how fractured the mods are compared to OptiFine, I can't suggest this modpack anymore and will have to recommend alternatives.

And I will reiterate, what I find extremely disappointing is how easy it has been to replace one of the mods with a low quality resource pack the minute it jumped to Quilt. No discussion with the mod author. The thing to learn with that is, as a mod author, I can't expect support from one of the de-facto OptiFine alternatives modpack. Now if I have users complaining about how fractured the mods are compared to OptiFine, I can't suggest this modpack anymore and will have to recommend alternatives.

I do not understand this argument, please elaborate. Here's my point of view:
You had made a Fabric mod that replicated OptiFine's better grass with all of its features and more. As of 1.19.3, you decided to leave Fabric for various reasons.
There were some interested parties who considered porting it or creating an alternative, but back then (and now) none exist.
So what's the best alternative? A resource pack. I looked around for available packs and they weren't satisfactory for several reasons (availability, maintenance, license, hardcoded textures etc) so I made my own.

No discussion with the mod author.

With all due respect, what kind of discussion did you expect? I honestly cannot understand.

I didn't request or try to convince you to port to Fabric anyway to respect your decision.
I didn't use any of your resources that your mod consists of, so no licensing issues.
The idea of "better grass" isn't unique in your mod in regards of patents or similar, so that is irrelevant as well.
If I skipped the mod and did not provide an alternative in FO, you could possibly have had more users run to you to blame, annoy etc. So I saved your nerves by not really blaming you at all.

I do not understand this argument, please elaborate. Here's my point of view:
You had made a Fabric mod that replicated OptiFine's better grass with all of its features and more. As of 1.19.3, you decided to leave Fabric for various reasons.
There were some interested parties who considered porting it or creating an alternative, but back then (and now) none exist.
So what's the best alternative? A resource pack. I looked around for available packs and they weren't satisfactory for several reasons (availability, maintenance, license, hardcoded textures etc) so I made my own.

My point is that now I know I can't expect modpacks to support me if I want to use better APIs that make my life easier and allow me to update more frequently. Or at least, not in the current state of things.
Aside from CurseForge, now that Modrinth has modpack support, and this modpack is on Modrinth as well, and considering that the launchers supporting Modrinth have better support for Modrinth, I think a variant of the modpack on Quilt is not too far-fetched, aside from the annoyingly increased maintenance burden, which I totally understand as I'm also a fan of lessening maintenance burden.

No discussion with the mod author.

With all due respect, what kind of discussion did you expect? I honestly cannot understand.
* I didn't try to convince you to port to Fabric anyway to respect your decision.

* I didn't use any of your resources that your mod consists of, so no licensing issues.

* The idea of "better grass" isn't unique in your mod in regards of patents or similar, so that is irrelevant as well.

* If I skipped the mod and did not provide an alternative in FO, you could possibly have had more users run to you to blame, annoy etc. So I saved your nerves by not really _blaming_ you at all.

So I did the most sensible thing and adapted to the situation in a way that causes the least friction to my users and you.

When I say discussion, I expected to at least be informed of the change. I only was made aware because someone brought it up in a totally random discussion on Discord. I at least appreciate not having attempted to convince me to get back to Fabric nor causing licensing issues. And I have in no way talked that the idea of "better grass" is unique.
Like, there's been talks here previously but not confirmation on the fate, that's what I at least wanted to know.

If I skipped the mod and did not provide an alternative in FO, you could possibly have had more users run to you to blame, annoy etc. So I saved your nerves by not really blaming you at all.

I'm not sure, so far I've seen users complaining at how bad the provided alternative is, and I have already people asking why Quilt so I already have tags on Discord to explain why.

My point is that now I know I can't expect modpacks to support me if I want to use better APIs that make my life easier and allow me to update more frequently.

I'd rephrase it as "mods cannot expect modpacks to follow their footsteps in important decisions".

When I say discussion, I expected to at least be informed of the change.

Everyone who is interested in following what changes are done to Fabulously Optimized are free to follow and discuss this GitHub repo and/or Discord, such changes are usually cross-posted and publicly discussed with the userbase.
I didn't notify you, the dev, because I didn't have anything to suggest or ask at the time.

That said, let's steer this conversation back to Quilt Loader itself. Any issues with specific mods can be discussed in separate issues or privately, if sensitive.

Status update, from newest to oldest news.

CurseForge Launcher 0.230 just gained Quilt support. (via). As always, their releases are gradual so not everyone will see it yet. Would be interesting to see how many new modpacks will come out of it, considering that Sodium, Iris, Mod Menu etc. have not returned to the platform.
Quilt added telemetry in Loader 0.19.2. The telemetry was planned to only collect how many users use Quilt in a month, but it collected more (via) and therefore is now disabled server-side.

FO stance is that the telemetry should either be removed (due to the indicent) or it should have a simpler opt-out mechanism as the current options are way too limited and difficult.
There is an RFC for removing the feature from the loader.

Internal drama (including the telemetry) has led to 11 staff members quitting Quilt (via) over 21 days. Most of the leaving members were moderators or otherwise only involved with the community (not development) but that does not instill confidence in the project's sustainability regardless.
Recently there haven't been any drastic changes from mods or the loader that would currently warrant switching to Quilt.

Sustainability update:

Previously mentioned telemetry was disabled serverside after an incident and fully removed with Loader 0.19.5.
Minecraft 1.20.2 has been around for 1 day over a month, with 1.20.3 already in snapshots and there is still no QFAPI yet for either.
Better mod conflict screen, which was touted to be one of Quilt Loader's strengths, is at least wording-wise available in Fabric Loader 0.14.23, though no visual elements are changed there at this point.
There are currently 2 Quilt modpacks on CurseForge, which shows that it hasn't caught on there, though that doesn't matter much to FO.

What matters to FO, is the mod marking. 2057 vs 511 * 20 = 10220 on CurseForge, 141 * 20 = 2820 vs 388 * 20 = 7760 on Modrinth. That's about 5x and 3x difference, respectively, which does matter because FO has a lot of users nowadays and they like adding mods to their instance.

There are still ways to go.


Amazon Books Analysis

Pull Request for ML-Crate 💡
Issue Title : Amazon Books Analysis

Info about the related issue (Aim of the project) : Analysis of the books from Amazon website.
Name: Sankalp Srivastava
GitHub ID: sankalp-srivastava
Idenitfy yourself:

[x] SWOC Participant ❄
[ ] JWOC Participant ☃
[ ] Contributor ✔

Closes: #90
Describe the add-ons or changes you've made 📃
Done a very detailed eda on the dataset. Few plots are interactive which would only be seen when the code block is ran. For final look of the notebook refer : https://www.kaggle.com/sankalpsrivastava26/amazon-bestselling-books
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested? ⚙
ran the notebook on kaggle
Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

I will get back to you by EOD. Please consider me, I'm stuck with some works @sankalp-srivastava

@abhisheks008 , take your time, no rush 😄


Feature/dashboard page + user search

This commit contains the refactored versions of page and user search.
Associated tasks: #8752 and #8753 .
Everything is tested and working fine on my development environment.
Comments:
While refactoring this i have found two general issues that should be fixed in the future:

"$(...).concreteEditableFieldContainer is not a function" on some bulk actions and on user detail page (and on all other places where in-page-editing is used)
the dashboard breadcrumb style is not visible for non-super-admin-users (permission problem?)

Really nice job!


Fix spacing on figure gallery on closed campaign. Fixes #4040.

Changes
Figure markup on closed campaign template wasn't up-to-date. Fixes #4040.
For review: @DoSomething/front-end

Looks good, are we still using theme functions to handle the markup of these gallery patterns?

We are, I just didn't want to take the time to refactor this to use them. :sweat:

Gotcha, this look good tho! :+1:

:sweat_smile:


Reverted Controller transformation code to resolve translation issue

Overview
Reverted Controller transformation code to resolve translation issue

azp /run

azp run

Hold releasing after this pr, there is a new api out this week and might as well update that too

Well the upm server is down anyway. Might hold up our approval process.

/azp run

Fixed the upm server


[PACE-83] Implement API paging

@bvdeenen and I discussed how we should implement paging, and we will follow AIP-158, including the skip parameter.
From SyncLinear.com | PACE-83

Datahub:

Input:

start -> skip
count -> page_size

Output:

start
count
total

ODD:

Input:

Page Number (int32) -> page number * size = skip
Size -> page_size

Output:

PageInfo

total
hasNext

Collibra:

Input:

limit The maximum items to return. -> page_size
offset The number of items to skip. -> skip
order

Output

none, only the resource(s)

Proposal is to translate the various implementations into a generic implementation.


As a developer , I want to Ensure system functionality under low battery conditions.

Acceptance criteria:
1.The vacuum must retain enough energy to go back to the charging station if the battery units are below the specified minimum amount.
2. It should stop cleaning and only foucus on return to charging station.
3.it must find out the nearest station to its present location .
4.I may use mechanism like backtracking to find out the way to charging station if there is no charging station near by .


printing tensors

Usage question.
When printing output tensors, I was using DumpTensors['conv0/output:0']. But this does not work during training as there are 4 towers (in my case) and I need to append the tower# id to the tensor name.
Any simple way the DumpTensor appends these output feature maps and prints a single tensor concatenated (or averaged) across all towers instead of one per tower?

Think of the 4 tensors as 4 independent tensors that happen to have similar names.
They are not necessarily concat-able at all.
You can implement this feature by writing a callback, either fetching all tensors to numpy and concat them there or create a concatenated tensor in the graph and fetch it.

Got it.

Is there no such thing as tower0/bnorm0/output:0, ie bnorm for tower0?
This is with respect to resnet topology (very first layer there).
When I dump tower0/bnorm0/output:0 i get an error but not when I print tower1/bnorm0/output:0.

Ok, so its called InferenceTower instead of tower0.
One question to understand the framework: Each tower has a copy of the model and gets some number of inputs (=TotalBatchSize/NumGPUs), during inference or when checkpointing, do you store the average of all the model tensors across the towers?

Actually, no, its called tower0/bnorm0/FusedBatchnorm:0 for some reason.

DumpTensors callback runs in every training step so I don't see why it makes sense to evaluate inference tensors in it. That's up to you, though.
The tensor name is supposed to end with "output:0". Getting "FusedBatchnorm:0" is a bug. I'll fix it soon.

do you store the average of all the model tensors across the towers?

No. And as I said tensors on different towers, though have similar names, are not necessarily of the same shape at all.

DumpTensors callback runs in every training step

Yes. That’s my mistake.
Any option to print tensor ops outputs during inference phase?

On Feb 20, 2018, at 5:10 PM, Yuxin Wu<EMAIL_ADDRESS>wrote:
DumpTensors callback runs in every training step so I don't see why it makes sense to evaluate inference tensors in it. That's up to you, though.
The tensor name is supposed to end with "output:0". Getting "FusedBatchnorm:0" is a bug. I'll fix it soon.
do you store the average of all the model tensors across the towers?
No. And as I said tensors on different towers, though have similar names, are not necessarily of the same shape at all.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

Using self.trainer.get_predictor() in a callback is the easiest way to do it. See http://tensorpack.readthedocs.io/en/latest/tutorial/inference.html.
You can also write:
class A(Inferencer):
    def _get_fetches(self):
        return ['conv0/output:0']

    def _on_fetches(self, outputs):
        print(outputs)


Replace govspeak steps background images with css counters

What
Replace the use of background images with CSS to indicate step numbers.
Component preview: https://govuk-publishing-compon-pr-993.herokuapp.com/component-guide/govspeak/steps/preview
Why
CSS counters are supported on IE8 and above so we can safely use them
to visually indicate the steps instead of images.
Added bonus is that numbers retain crispness with zoom :)
Bonus

numbers retain crispness with zoom :)
as images are part of govuk_frontend_toolkit this further reduces the dependency on it

Visual Changes
There are minor visual difference, so needs a designer consultation.
Old:

New:

New with long text:

New (left) vs old (right):

Where are step icon images located, as they can now be deleted?

Can the numbers in the circle be a bit smaller?
Would you ever get double figures? What does that look like?

@jeremyhhy2
font-size is currently 16px, can drop to 14 but will need top alignment offset adjustment
with double digits

@markhurrell  @miaallers What do you think?
@kr8n3r Have you tried adjusted the numbers to the right slightly?
Feels like the numbers are not centred inside the circle, maybe because we are using 16px? The number is like 1 or 2 pixels off to the left?

@jeremyhhy2 I've added more items to the preview page https://govuk-publishing-compon-pr-993.herokuapp.com/component-guide/govspeak/steps/preview
you can play around in the browser and suggest changes

@kr8n3r, @miaallers suggests that we could use the tabular version of the font for numbers. what do you think of that?

tabulars are wacky :) see below

would need drop font-size and increase padding. that would result in larger padding on 0-9 than double digits

closing in favour of leaving it as it is


Infer chained response types in Pipeline

What?
Adds support for inferred pipeline types like this:

How?

A generic type representation of the commands array is stored on the Pipeline class itself
The type of .chain is then updated to return a Pipeline type with whatever command was just chained fed into the class-level generic
Finally, the type of .exec is updated to return the type of the commands array mapped to each item's response type. Kept the empty case as unknown[] for backward compatibility.

Gotchas
TS thinks that each .chain call returns a new Pipeline instance, which means that the type inference only works if the chain is kept intact from pipeline() to exec(). Splitting the pipeline up for use in loops etc will still require manually overriding exec<['like', 'this']>
const p = redis.pipeline()

for (const x of [1,2,3]) {
  p.set('foo', 'bar')
  p.get('baz')
}

const result = await p.exec() // TS: const result: unknown[]

closing in favor of #355 because the CI won't run on foreign PRs due to secrets involved :/


Add commands to reboot the server, Nginx, MySQL, and Postgres

Added the following commands:

reboot:server
reboot:nginx
reboot:mysql
reboot:postgres

Given the nature of what these commands do, they require the --confirm option.
I added a base RebootCommand so that it's easy to build out more reboot commands as they are added to the SDK (e.g. redis and supervisor are in the Forge UI but not the API yet)

Nice. Thanks!

My pleasure!


SHAP in C++

An idea about SHAP: the R package of LightGBM offers native R code to calculate SHAP decompositions. This is great but e.g. lacks the relevant decompositions into pairwise contributions (=interaction decompositions). So an R user does not have direct access to SHAP interactions for LightGBM. Python users will usually rely on the "shap" package in Python but R users are a bit lost.
In XGBoost, there is a neat C++ implementation that also covers interaction decompositions. It is handled through the predict method interface.
https://github.com/dmlc/xgboost/blob/master/src/predictor/cpu_predictor.cc
Since model explainability gets more and more of key relevance, I'd love to see something like this for LightGBM as well.

Hi @mayer79 !
Actually, LightGBM has native SHAP values calculation in cpp from the original author. And I think that R-package calls these cpp functions, but do not re-implement it in the R code.
Unfortunately, it is unlikely that new features from SHAP package like feature interactions will be added into LightGBM code.
Please refer to https://github.com/microsoft/LightGBM/issues/1350#issuecomment-395903942.

I see... bad news for R users then!


Implement dataloader

We need the perceptron to receive data and train on that data. This requires a module that will facilitate data management

We need the perceptron to receive data and train on that data. This requires a module that will facilitate data management

Given mnist is very popular and can be imported from a variety for places, what should be done for this issue specifically? My understanding was that this was to load that data from our local machines, but i wanted some clarification.

While it's true that dataloaders in other machine learning libraries have the MNIST dataset available to download, that is not in the scope of the project. However, downloading popular datasets is a feature that we can add later on.


Unable to use OPENAILLM class with docker hosted vllm

Wrote the according to the following example at https://distilabel.argilla.io/latest/sections/how_to_guides/advanced/serving_an_llm_for_reuse/#serving-llms-using-vllm:
from distilabel.llms import OpenAILLM
from distilabel.pipeline import Pipeline
from distilabel.steps import LoadDataFromDicts
from distilabel.steps.tasks import TextGeneration, UltraFeedback

with Pipeline(name="serving-llm") as pipeline:
    load_data = LoadDataFromDicts(
        data=[{"instruction": "Write a poem about the sun and moon."}]
    )

    # `base_url` points to the address of the `vLLM` serving the LLM
    llm = OpenAILLM(base_url="http://<IP_ADDRESS>:8000", model="")

    text_generation = TextGeneration(
        llm=llm,
        num_generations=3,
        group_generations=True,
        output_mappings={"generation": "generations"},
    )

    ultrafeedback = UltraFeedback(aspect="overall-rating", llm=llm)

    load_data >> text_generation >> ultrafeedback

Running in to the following error :

    WARNING  ['distilabel.step.paraphrase_validation'] Subprocess traceback:                                                                                step_wrapper.py:245

                             Traceback (most recent call last):
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/distilabel/pipeline/step_wrapper.py", line 229, in _non_generator_process_loop
                                 result = next(step.process_applying_mappings(*batch.data))
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/distilabel/steps/base.py", line 642, in process_applying_mappings
                                 for output_rows in generator:
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/distilabel/steps/tasks/base.py", line 267, in process
                                 outputs = self.llm.generate(
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/distilabel/llms/base.py", line 358, in generate
                                 return self.event_loop.run_until_complete(
                               File "/usr/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
                                 return future.result()
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/distilabel/llms/base.py", line 328, in _agenerate
                                 return await asyncio.gather(*tasks)
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/distilabel/llms/openai.py", line 268, in agenerate
                                 completion = await self._aclient.chat.completions.create(**kwargs)  # type: ignore
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/openai/resources/chat/completions.py", line 1339, in create
                                 return await self._post(
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/openai/_base_client.py", line 1816, in post
                                 return await self.request(cast_to, opts, stream=stream, stream_cls=stream_cls)
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/openai/_base_client.py", line 1510, in request
                                 return await self._request(
                               File "/home/gpuwork/LLM-Postraining-Synthetic-data-generation/venv/lib/python3.10/site-packages/openai/_base_client.py", line 1611, in _request
                                 raise self._make_status_error_from_response(err.response) from None
                             openai.NotFoundError: Error code: 404 - {'object': 'error', 'message': 'The model `` does not exist.', 'type': 'NotFoundError', 'param': None, 'code': 404}

    The example explicitly mentions to keep the model name blank as ''

Hi @akshaypn,
llm = OpenAILLM(base_url="http://<IP_ADDRESS>:8000", model="")
Could you please replace the model=""  with the model that you are serving via vLLM and let me know if that works?