Unreal Tournament 2004: Cannot tab back into the game

Hello, I apologize for posting a Windows issue, but when using dxvk with UT2004 I am unable to maximize the game after alt-tabbing when playing fullscreen. The game is still running (audio plays), but I can't tab back in.
Software information
Unreal Tournament 2004, both 32 and 64 bit executables when using dxvk. I tried both 32 and 64 bit d3d9 dlls for the respective executables.
System information

GPU: 6800 XT
Driver: 21.4.1 / 2.0.179
DXVK version: 1.10.1
OS: Windows 7 x64

Apitrace file(s)
https://mega.nz/file/n9lCmTzC#4EW-FPotPU2WosMTHn1zzSeYcI8tNOVUt12qn4DtiHQ
Log files

d3d9.log: UT2004-win64_d3d9.log
dxgi.log: Empty file

What do you mean, you cannot alt-tab back in? What actually happens?
Please also try the latest master version of DXVK. You cna find a build here: https://github.com/doitsujin/dxvk/suites/6067454616/artifacts/209680631

Does it help if you make a file called dxvk.conf next to the exe and insert d3d9.enableDialogMode = True ?
To make sure it's picking up the conf file you can enable the hud in it also.

Sadly that did not help. I enabled HUD as you suggested to confirm it's reading the conf.

I remember not being able to alt-tab while using d3d8to9 and dxvk either, with the original 32-bit version of the game (which only has d3d8 support). And it doesn't provide a non-exclusive or windowed fullscreen mode to work around the problem, sadly. I always thought it was a Wine problem, since AFAIK WineD3D also doesn't handle alt-tabing here very well.

@Calypto could you try with this PR? https://github.com/doitsujin/dxvk/pull/3316. You can find a download of it here https://github.com/doitsujin/dxvk/actions/runs/4537356630
First try it without anything extra just to verify its still an issue, it shouldn't do anything new out of the box besides what has been changed on master since you tested last time.
If it still happens then make a file called dxvk.conf where the dxvk log files appear (usually next to the exe but not always) insert d3d9.deviceLost = True and try again.

Please reopen in case the issue exists on Windows 10/11 or Linux.

It still happens on Windows 10 21H2 and DXVK version 2.1.

Please test the very latest master

Sorry, by latest master you mean 2.1?

No, I mean the development version as of 20 minutes ago.

Now, when tabbing out, the game gets stuck on the last frame before tabbing out. If I try to alt tab again the game minimizes. If I try to maximize the window, the game crashes.


Shift-Tabbing on desktop in IE and Firefox is not working

General information

SDK version: 3.52.1
Environment: Sandbox
Browser and OS : IE11, Chrome 77.0.3865.75 (Official Build) (64-bit), and Firefox 69.0

Issue description
This is a continuation from https://github.com/braintree/braintree-web/issues/380
With 3.52.1, tabbing forward now works. A lot better than before.
However, Shift-Tab ( to go backwards ) when hosted field has focus ...:

Works with Chrome
Does not work In IE ( IE11 at work ) ...e g. stuck on the hosted field
Works only if you do it twice In Firefox ... e.g. do Shift-Tab twice to get unstuck from hosted field

Attached is a ZIP file with a self-contained HTML using 3.52.1 and using hosted fields. Just replace the "sandbox_xxxxxxxx" with your own static authorisation key, then open with your browser. Do tabs and shift-tabs in IE and in Firefox.
braintree-test.zip

Thanks for the report, we'll take a look.

This should be fixed now in v3.53.0


Update docs

Summary

Screenshots

Checklist

[x] My code follows the code style of this project and passes make format.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] My change has adequate unit test coverage.

@homanp, thank you for the pull request! Overall, the changes look good. I have a suggestion to improve the code:
In the concepts.mdx file, you added a table to list the available datasources. It would be helpful to add a header row to the table to make it more readable. Here's an example of how you can modify the code:
+| Datasource                       |
+| -------------------------- |
+| `PDF`                      |
+| `TXT`                      |
+| `CSV`                      |
+| `MARKDOWN`                 |
+| `PPTX`                     |
+| `DOCX`                     |
+| `XLSX`                     |
+| `YOUTUBE`                  |
+| `WEBPAGE`                  |
+| `AIRTABLE`                 |
+| `SITEMAP`                  |
+| `URL`                      |
+| `GITHUB_REPOSITORY`        |

This will make it easier for readers to understand the table structure. Great job on the pull request! Let me know if you have any questions.


Ops: Add Multiple custom access logs and Header field for ATS

Currently TO supports only one custom access log file by configuring the "LogFormat" and "LogObject" parameters for "logs_xml.config". We have a requirement to support multiple custom access log files. As ATS does support this, we are planning to extend "LogFormat"&"LogObject" on TO, and add extra 9 groups (9 should be enough) of parameters like: "LogFormat1"&"LogObject1", "LogFormat2"&"LogObject2" ... "LogFormat9"&"LogObject9". Only when "LogFormatN"&"LogObjectN" are configured, they will appear in "logs_xml.config"; otherwise the file does not change, so the current behavior does not change either.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/700/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/659/

The UT failure above seems to be caused by the following line of existing code in ApacheTrafficServer.pm:
$self->app->log->error("Parameter package.trafficserver missing for profile ".$server->profile->name . ". Assuming version $ats_ver");


Run demo on nginx ?

Can we run the human demo on NGINX?
If so any recommendations?
Thanks

of course, no reason why not.
no special recommendations except path to modules must be resolvable (and path to WASM binaries if you use WASM backend).
if unsure, you can always start npm run dev which starts built-in web server and monitor incoming HTTP requests and make sure they are handled correctly by NGINX. but again, built-in web server is just there just for help, when people don't have their own web server.
and if you get any exceptions noted in browser inspector, check your server's content-security-policy - I had to relax my locked down server for WASM loading and web workers.

of course, no reason why not.
no special recommendations except path to modules must be resolvable (and path to WASM binaries if you use WASM backend).
if unsure, you can always start npm run dev which starts built-in web server and monitor incoming HTTP requests and make sure they are handled correctly by NGINX. but again, built-in web server is just there just for help, when people don't have their own web server.
and if you get any exceptions noted in browser inspector, check your server's content-security-policy - I had to relax my locked down server for WASM loading and web workers.

Thanks !

Thanks !


Fix use of insertCSVFromPath

Fix issue pointed out in https://github.com/duckdb/duckdb-web/pull/1548

I already created an MR for this which also fixes another issue https://github.com/duckdb/duckdb-wasm/pull/1491

Ah, thanks for pointing that out. I missed that.


Bump CHANGELOG to 4.5.2

Coverage remained the same at 65.147% when pulling 3bfb7cf0b86083fa63602343298f4186bf3ed358 on compulim:bump-changelog-4.5.2 into 08468b33f5825ab31e6ed88f27fee275492a3c87 on microsoft:master.


BUG: Focusing on search bar and then clicking outside anywhere redirects to gallery

What happened?
A bug happened!
https://www.loom.com/share/8e0f8669d834436085f3c563e33756e6
Please reproduce in steps
Go to ... Click on .... See error
Expected Behavior
I've expected ...
What browsers are you seeing the problem on?
No response
At which address did you encounter bug?
No response
Are you logged in?
No response
Which wallet you are using?
No response
At which chain did you encounter bug?
No response
Screenshots
Paste from your clipboard or upload screenshots/video
Relevant log output
No response
Payment link for reward
https://kodadot.xyz/transfer/?target=EzGc4s9PgCPx1YnF3fqzhLzVHpHMTL4LWPScwpDrR8JKgSU
Code of Conduct

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

good catch! happening on both mobile and desktop


Pygments relies on global imports of its own modules, breaking local installs

(Original issue 1448 created by tabatkins on 2018-06-16T14:35:44.286978+00:00)
The Pygments source files import each other like from pygments.foo import bar.  If you have a globally-installed Pygments, this'll import correctly.  But if you also have a local version of Pygments in some project, the local version will end up importing from the global version, and then various things will fail.
(In particular, the type-check that occurs at https://bitbucket.org/birkenfeld/pygments-main/src/default/pygments/lexer.py?fileviewer=file-view-default#lexer.py-431 will fail, because lexers.py has imported the global version of _TokenType, but my code is importing the local version of token.py, whose instances are all derived from the local _TokenType, so they fail the type-check.)
This can be easily fixed by using proper relative imports, like from .foo import bar - this is how I fixed it in my local copy. I'm happy to submit a PR to switch everything to relative imports, if that would be accepted.
(You can see the failure, attendant stack-trace, and fix in https://github.com/tabatkins/highlighter/issues/5.)

Most Python packages are not compatible with vendoring them into others as subpackages. Whether to use "proper relative" imports or absolute ones is mostly a style choice, so I'm going to decline this.


Did we use gamma correctly? It's an array, but we only ever use the first element

If gamma is the same for each stage, only one LU decomposition is used for each stage (page 103 Hairer and Wanner, 1996). This may be why there is only one gamma used. Verify that this really is correct
Ideas

Check our implementation against existing implementations

I think [1] produced these codes
KPP, which may be based off the previous

[1] Hairer, E., Wanner, G., 1996. Solving Ordinary Differential Equations II: Stiff and Differential-Algebraic Problems, 2nd edition. ed. Springer, Berlin ; New York.

It appears that any gamma past index 0 is only used for non-autonomous equations.
https://github.com/KineticPreProcessor/KPP/blob/main/int/rosenbrock.f90#L612-L615
Autonomous equations are those that are independent of time $F=F(y)$ and non-autonomus equations are dependent on time $F=F(t,y)$. In our case, I think we are autonomous equations.
Even though the jacobian and forcing are physically dependent on time, this information is already accounted for in the calculation of the rate constants which are not recalculated during timestep refinement.
@sjsprecious @mattldawson @mwaxmonsky @boulderdaze. I think we can close this issue because of this. What do y'all think?

@K20shores I think you are right that the chemistry system is an autonomous equation and the usage of gamma parameter is correct here.

I think your reasoning is well described for me to believe the system solves autonomous equations. I agree with you.


Rare NPE at StatefulRedisConnectionImpl.java:187

Hello,
I use Lettuce 4.2.2
and several times I have seen NPE when invoking
com.lambdaworks.redis.api.async.RedisStringAsyncCommands#setex
Caused by: java.lang.NullPointerException: null
	at com.lambdaworks.redis.StatefulRedisConnectionImpl.dispatch(StatefulRedisConnectionImpl.java:187)
	at com.lambdaworks.redis.AbstractRedisAsyncCommands.dispatch(AbstractRedisAsyncCommands.java:1805)
	at com.lambdaworks.redis.AbstractRedisAsyncCommands.setex(AbstractRedisAsyncCommands.java:845)

But it happens under load in production. At speed of 20-40 requests per second to Redis.
Looks like concurrency issue. Could you easily spot any?
I would like to test with 4.3.3 version, but can not do it easily, because my other library depends on Netty 4.0.

First, Lettuce 4.3.3 is compatible with both netty lines, 4.0 and 4.1.
It looks like you're using transactions on a single connection that is shared across multiple threads. Lettuce connections are thread-safe in general but transactions impose a state on the connection. Please assign each thread, that is executing transactional work a dedicated connection. If that's not possible, you might want to use pooling. Threads/code paths that don't do any transactional work may still share a single connection.

In this code path I am not using transactions. I have deployed with Lettuce 4.3.3 and Netty 4.0.49 and seems to work well. I don't observe the same issue yet.

The NPE is caused by a field access when the connection is in a transactional state hence the hint towards transactional use.

I don't really use tx for that specific connection. My setup is like this. I have a single com.lambdaworks.redis.RedisClient (maybe it is the problem). And then I create connections

com.lambdaworks.redis.RedisClient#connect(com.lambdaworks.redis.codec.RedisCodec<K,V>)
com.lambdaworks.redis.RedisClient#connectPubSub()
com.lambdaworks.redis.RedisClient#connect()

First one for CRUD, second to listen expirations and third for Tx (single thread).
I experience that NPE at 1st CRUD connection, which I use in async mode RedisAsyncCommands<K,V>
something like this.
return crudCommands.get(key)                 .toCompletableFuture()                 .thenApplyAsync(Optional::ofNullable, nettyHandlerExecutor);     }
But it is really rare. I have two nodes in prod and just single NPE at one of them since I deployed 21 hour ago.

On a different note: Optional::ofNullable isn't a blocking operation hence you don't require thenApplyAsync (from a Lettuce perspective). This call makes only sense if the callback is blocking or you want to switch threads.
A single RedisClient is fine to create multiple connections. The client encapsulates mostly settings and thread pools.
If you don't interact with StatefulRedisConnectionImpl.multi directly (via reflection or similar), then your issue sounds like a multi-threading/visibility issue. The code block in Lettuce is guarded against null so there's nothing to do for Lettuce to solve the ticket.

Yes, I know ofNullable is not blocking. Just I change a thread here and then callbacks to CF which are added later are invoked in a custom thread, not in event loop thread.

Okay

Yes, that's my point. That it looks like  multi-threading/visibility issue in Lettuce StatefulRedisConnectionImpl. Looks like there a race condition here.


Deploy

-Get domain name, maybe wait until Wednesday meeting so you can get input on domain name
-Get everything on AWS and have website up and running

Need @tanzeelak or frontend to get their stuff running in docker. We need backend and frontend under the same docker-compose to get it up on AWS.

It's up at whatsmappening.io


Indentation with comment on previous line

A general problem I'm seeing is that the indentation doesn't account for comments on the previous line. Example:
foo = doSomething 123  -- Do something important.
>>>>bar

bar will be indented &shiftwidth because of the operator on previous line rule, which is . here.
A nice solution for this would be to run all the checks as if the previous line didn't have a comment, as long as: a) we're not inputting a comment, and b) if there is a comment, it's not the only thing on the line.

Good point. This should be relatively easy, I have some working code here but I want to check for some edge cases before pushing it.

I've pushed a change to a new branch commentindentation. I'm only checking for trailing -- right now, trailing '{-' will follow once I've got the time ^^.

Nice! Going to try this out.


ICDarkKnob does not display actual value

The knob works but in the middle bottom of it, the actual value is not actualised when I move the knob

this happens only when I open a fullUI for Phausto, not when I open single knobs


Merge management into main

This pull request includes significant updates to documentation, including the addition of a Code of Conduct, Contributing Guidelines, and detailed weekly reports. These changes aim to establish clear community standards, provide guidance for contributors, and track project progress.
Documentation Added:

CODE_OF_CONDUCT.md: Added a comprehensive Contributor Covenant Code of Conduct to ensure a harassment-free experience for all community members.
CONTRIBUTING.md: Introduced Contributing Guidelines, including instructions for forking and cloning the repository, branching strategy, code style, commit messages, and pull request procedures.

Project management updates:
Updating the readme to include the new member of the team @Loic-nogues .
Adding the weekly reports of weeks 1 and 2
Filling the management artifact


Invalid data found when processing input

tv.danmaku.ijk.media.player.IjkMediaPlayer: Error (-10000,0)
My log::
http://i.prntscr.com/riBxWCeVQXW3aaZzim6Tfw.png
while I will use mobile data and play some video means am getting like this. but in WIFI connection everything working fine

https://emenatormediadev.com/live/feedvideo.php?id=3360&type=sd >> this is my test video

try to replace ip to the hostname,I guess the are something wrong with the dns

implementation 'com.github.tcking:giraffeplayer2:0.1.25' >> i implemented this ver

sion

I mean the video url, some mobile carrier‘s dns will get wrong result

In Airtel and idea network working fine..but  My JIO network have the same issue..playback error

Any solution to this? I too get this issue where it works on wifi mostly but not on mobile data.
Hit dns cache but connect fail hostname = example.net, ip =

2019-10-11 04:35:32.334 20307-23907/com.example.android.dev D/IJKMEDIA: Statistics: 228 bytes read, 0 seeks
2019-10-11 04:35:32.337 20307-23907/com.example.android.dev E/IJKMEDIA: https://example.net/public/c034c19c-048c-4dec-852f-7a7ae283af1e.m3u8?srvID1: Connection timed out

Nope still not yet get solution for this issue


[$500] Expense - LHN preview for submitted report shows "You" or user's email with no context

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

Version Number: v1.4.19-1
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal team
Slack conversation:
Action Performed:
Precondition:

User is an employee (not an admin) of a Collect workspace.
User has a display name.

Go to workspace chat > + > Request money.
Create a manual expense.
Click on the expense preview.
Click Submit on the expense preview.
Note that expense report preview in LHN.
Return to the main chat.
Click on the expense preview.

Expected Result:
In Step 5 and 7, the IOU report preview displays "You submitted this report to...".
Actual Result:
In Step 5, the IOU report preview displays just "You".
In Step 7, the IOU report preview displays the user's email.
Workaround:
Unknown
Platforms:

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

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

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/93399543/e32c5a9d-9bea-483f-9810-d78adb843282
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~018e710b7d92586ec2
Upwork Job ID:<PHONE_NUMBER>522711552
Last Price Increase: 2024-01-12

Proposal
Please re-state the problem that we are trying to solve in this issue.
The LHN last message preview shows "You" after submitting an expense and changes to an email after refresh.
What is the root cause of that problem?
After we submit the expense, the BE will return the last message as "You"

If you notice the report action message, it has 4 arrays and the first array message is "You". This is a similar case of https://github.com/Expensify/App/issues/32285.
After we refresh the web, the OpenReport API will be called and it will return a last message of our email.

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

For the first case, we can use the same approach as https://github.com/Expensify/App/issues/32285.
In OptionsListUtils.getLastMessageTextForReport, add a new case for submitted action.
if (ReportActionUtils.isSubmittedExpenseAction(lastReportAction)) {
    lastMessageTextFromReport = _.reduce(lastReportAction.message, (acc, curr) => `${acc}${curr.text}`, '');
}

For the second case, investigate on the BE why OpenReport returns our email as the last message.

Checking internally on priority here

Thanks for the proposal @bernhardoj.
As stated by @bernhardoj, we may need some backend changes to resolve the issue completely. @peterdbarkerUK, could we please get an internal engineer assigned to investigate the backend for this issue??

Correct @peterdbarkerUK, I think we can close this.


Fatal error: palette assignment parameter search matrix failed to find any suitable parameters

Me again lol,
I'm trying to generate a tileset using compile-primary and I have the following error:
warning: ./my-tileset/assign.cfg: cached compilation settings not found [-Wmissing-assign-config]
note: running full parameter search matrix, this may take awhile...

fatal error: palette assignment parameter search matrix failed to find any suitable parameters
note: please see the following wiki page for help with working through this error:
      https://wiki-page-link-goes-here.com
terminating compilation of ./my-tileset/

This might be relevant: I was having the "running full parameter search matrix, this may take awhile..." message for a long while, and I accidentally closed the terminal. When I ran the command again, I got this error.
[EDITED] I'd like to avoid losing all the maps I've made using the previous iteration of this tileset; is there a way to rollback what Porytiles has done without losing everything?
Just for context, these are my three .PNG images:

Unfortunately this isn't really a bug with Porytiles. Rather, it's the message you get when the palette assignment algorithm is unable to find an allocation that covers all of your tiles. Palette assignment is a variant of the bin-packing problem, which doesn't have a known polynomial time solution. Porytiles has to do a lot of clever tricks to find a solution in most cases. Over time, I will continue improving these tricks so that this error message is less frequent, but as it stands it's not a bug.
So how to solve this error message? Typically, you either need to reduce the number of unique colors, or better layerize tiles with conflicting color families. For example, you have a lot of tiles in your Pokécenter that mix reds with greys and blues. If you separated that out better (for e.g. by putting the entire red roof on its own layer, putting the red P.C. and Pokéball symbol on their own layer, etc) you might get better results. If you're in the RHH discord server, go ahead and ping a user named voluptua.  He had this problem and I helped him fix it -- he can probably show you an example of how he layerized his Pokécenter.
Hope that helps.

If I get some time I will download your three layer PNGs and see if I can modify them a bit so they will compile.

I'd like to avoid losing all the maps I've made using the previous iteration of this tileset; is there a way to rollback what Porytiles has done without losing everything?

Also, if you are not using Git to track your project changes I highly suggest you drop everything and learn the basics now. It will save you so, so many headaches in future :)

Sorry about the bug label, I don't know how it got there. I wasn't trying to report an actual bug, but I opened this issue because the error message was (to me) unclear and I thought it wasn't an error message that the end user was supposed to see (I thought Porytiles had been cut off while editing the project files in pokeemerald and had basically corrupted the tileset portion of it). My bad. Maybe a FAQ or error-related section in the wiki with the main error messages and their explanations could
If you're telling me that it's just the .PNGs themselves that are the issues, that's pretty reassuring, I'll just keep tinkering with them (and maybe ask voluptua on Discord if I get really desperate lol) and eventually it'll work :)
I absolutely do use Git and love it :) I just hadn't committed yesterday's changes (bad, I know) and was afraid of losing them.
Thanks again for the help and kindness and for porytiles!

Maybe a FAQ or error-related section in the wiki with the main error messages and their explanations could help other people with similar issues?
I know you're doing unpaid work and probably busy with more important stuff, so if you want I can start by creating that page myself and put in this error and quoting your explanation (not entirely sure if I can open a PR for the wiki itself, but if this is something I can do I'm all for it)

Sorry about the bug label, I don't know how it got there.

Oh don't worry about it. I realize that error message definitely makes it sound like something buggy is happening. As you can see in the error message, there's a placeholder wiki link there (since I haven't gotten around to writing an explanation wiki page yet). My eventual aim is to have a video tutorial series as well, but you know how it goes, only so many hours in a day.

I thought Porytiles had been cut off while editing the project files in pokeemerald and had basically corrupted the tileset portion of it

Ahhh ok I see your concern. Nah you are good. Porytiles doesn't write any files until the very end. So if you cancel it partway thru the assignment search, it will just exit.

If you're telling me that it's just the .PNGs themselves that are the issues, that's pretty reassuring, I'll just keep tinkering with them (and maybe ask voluptua on Discord if I get really desperate lol) and eventually it'll work :)

Yeah just keep tinkering with it and eventually you should find something that compiles. I'll try tinkering at some point too. I like to tinker with user images when they hit this case, because it gives me insight into how I can improve the bin-packing heuristics, or tweak the algorithm in general.

not entirely sure if I can open a PR for the wiki itself, but if this is something I can do I'm all for it

Yeah I am also not sure how to (or if you can) do that on GitHub. But don't worry about it! I'm just happy users are filing issues, because it means somebody is actually using it :)

Hi @grunt-lucas! I know this is a closed issue, but I stumbled on the same problem and this thread actually gave me a lot of insights, so thanks for explaining!
Now I was wondering if this is something porytiles can give more information to the user, so they can go and fix that themselves. Thinking that it would be useful if it could output what colors could be removed from the pallete so it helps the algorithm. Altough I believe this gets obvious if you look at your tileset colors in an interface like the one from Aseprite:

In my case the CP colors also were the problem. It definitely would be helpful if porytiles could tell that to me somehow.
I'm fairly new to the GBA world so sorry if what I'm saying doesn't really make sense. I admit I also didn't look in depth on how the program works, but I'd love to help with that if it is something feasible and desirable. I'll try to test some changes in the code myself but I'm not used to cpp programming so it will take a while!

@lsfgrd that's a great suggestion. I recall someone made a similar suggestion to me in a Discord chat somewhere. An idea would be for Porytiles to try automatically removing colors that are similar, recompiling, and seeing if that works. If so, it could report that to the user.
I need to think about this a bit more. Because sometimes, it's not color count that's an issue. Sometimes the user can simply layerize tiles better and it will compile with the same color count. So I wouldn't want the feature to mislead users into thinking they need to settle for a sub-par color distribution. Ideally I want people to understand how pokeemerald tilesets work so they can think it through themselves. Ideally, Porytiles should be a tool that helps you speed up a process you already understand, not a tool that does "black magic" to make your tile PNGs work in-game.


[Font] Allow overriding advances, offsets and kerning in the ImageFont import settings.

Adds support for setting custom ascent/descent.
Adds support for advances and offsets for the glyph ranges.
Adds support for kerning.

Currently, there's no convenient UI for setting values, but it can be added as an advanced import dialog.

Thanks!


webAccount.username always null

In the WebAccountManagement sample, the scenario "login with default Microsoft Account" seems to login ok, but the webAccount.userName is always null.
Also, when,extending the scope with wl.emails in,addition,to wl.basics, no emails information is available.
Would This ne because I run,the code from a Windows 10 build 10240 included in,a,professional domain ? Or is This due to annoter reason ?
Laurent

Normally you would use the token gained from the RequestTokenAsync with the Live APIs (https://msdn.microsoft.com/en-us/library/hh243641.aspx) but right now there is not a LiveSDK for Universal Windows Apps. It is coming, but for now the only way is to use OAUTH. (https://msdn.microsoft.com/en-us/library/hh243647.aspx)

So is the UWP LiveSDK still coming?

There is going to be a set of new SDKs that replaces what the LiveSDK used to do pre UWP. (https://github.com/liveservices/LiveSDK-for-Windows/issues/58) But the logic is still the same, get a token from RequestTokenAsync and use it with these APIs.


RDK-29959:New Plugin MaintenanceManager.

Reason for change: Added new Plugin MaintenanceManager.
Test Procedure: Refer to Jira Ticket.

@anand-ky  could you please review and merge the change. +1 from jenkins


Added Shell Sort Algorithm

Added Shell Shorting Algorithm.
I have 2 Ideas for this repo,
1st let me know if I can change the file extension of programs that were provided by other people as txt files into their respective language extensions or not.
2nd I want to organize all of the files with their respective topic name within a folder that people are contributing to.
For Example -
All sorting Algorithms in a Folder Called Sorting Algorithms
All Dynamic Algorithms in a folder called Dynamic Programming
let me know if you want me to go ahead with these 2 ideas

Hi Dear @sumanrox
Great code
Thanks for your contribution......
Show your support on my youtube channel web Pixar(The institute of coding)
like , share , subscribe
youtube - https://youtu.be/5qnQjgdpFPg
telegram-channel - https://t.me/WebPixar
join our telegram channel for more goodies , swag packs


.prettierrc format problem in documentation

I followed the README and the issue  referenced to solve the installation problem, and yet in the README file it says to put the config in the .prettierrc file like this :
// .prettierrc
{
  "plugins": ["prettier-plugin-go-template"]
}

but when I did that the prretier plugin threw a bunch of errors about invalid config file format.
Seems that the config  file should be in YAML format and not JSON. So I changed the file like this:
---
goTemplateBracketSpacing: true
plugins:
  - prettier-plugin-go-template

Seems there is an upstream prettier plugin change in the config file parsing that should be reflected here in the documentation.

Weird, the prettier docs still state that json or yml are ok:

https://prettier.io/docs/en/configuration.html

I din't follow up on that , but yeah it says JSON too! I don't know maybe I did something wrong the first time. But I'm sure my json config was correct.


fix ULP makefile for multiple source files

The original does not handle ULP projects with multiple .S sources.
Only the first file was linked into the final binary.

 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.

Thank you for the PR @tomtor, it was cherry-picked as 58b411a5fe5345b3f3ad1d2d4c20d909b0ffbfa1.


[Device Support Request] Various HUE & Paulmann devices

Is your feature request related to a problem? Please describe.
no
Describe the solution you'd like
Infos about if the following devices are compatible with ZHA,
and if not, it's an device request.

Device signature
those are just device id's from deconz API, hope this helps to identify the devices
LCT015
LTW012
LTW010
LCT007
LTW013
LWG004
LCL001
500.48
500.43 Switch Controller (Paulmann)

Additional context
Planing to move from deconz to ZHA, and want to check compatibility first.
Already checked: https://zigbee.blakadder.com/zha.html and removed the compatible ones from the list.

The Philips Hue devices (LCT*, LWT*, LTW*) just work.
LCL001 is listed on blakadder as working, it probably just does.

ok, thx.
ANy hints about the paulmann devices:
500.48
500.43 Switch Controller (Paulmann)
?

If you have more than a handful of devices, do yourself a favor and get a second coordinator.  Keep both running in parallel and move devices at your leisure instead of a rushing to do it all at once.

thx for the hint.
already don this way and got an sonoff 3.0 dongle plus.

Like mentioned, basically all Hue devices are supported.
No idea about the Paulmann devices. If they follow standards, they'll work.
If you have issues with those devices, open a new issue and provide the requested information (for which you need to have the device in ZHA).


How to upgrade RealSense SDK 2.0 (which was installed using "building-from-source" method)?

Required Info

Camera Model
D435i

Firmware Version
<IP_ADDRESS>

Operating System & Version
Linux (Ubuntu 18.04)

Kernel Version (Linux Only)
5.3.0-28-generic

Platform
PC

SDK Version
2.0 (v2.36.0)

Language
C++

Segment
others

Issue Description
I had installed RealSense SDK 2.0 using building-from-source method by following installation.md. However, as I have been facing an issue #7313 I want to update the current SDK v2.36.0 to the latest one v2.38.1. So, how can I directly upgrade this SDK to the latest version without uninstalling it?
I found steps for upgrading the SDK in distribution_linux.md but those are for the pre-built packages. I couldn't find similar steps for building-from-source installation method.

Hi @milan-r-shah   I believe that upgrading on the distribution method is practical because it is compartmentalized into a very small number of packages.  Whereas overwriting just some of the files on a source-code build with newer versions may lead to problems.
The standard procedure with the source code method of installation is, of course, to do an uninstall, clean and install with sudo make uninstall && make clean && make && sudo make install
If you are seeking to upgrade an existing version because of concern about the time that it takes to build the entire SDK, you can speed up the build process by using multiple cores of your computer's processor.
This is done by adding a jx term to the make command, with 'x' representing the number of processor cores that can be used.  librealsense recommends -j8, though more powerful high-end processors may be able to make use of higher values such as -j16.  Bear in mind that on low-end devices, using -jx may cause the build to randomly hanf.
Googling for how many cores do i have provides information about how to determine how many cores your particular computer has.
Below is the -j8 version of the build instruction from the librealsense source-code install documentation:
sudo make uninstall && make clean && make -j8 && sudo make install

hi @milan-r-shah   Do you still require assistance with this case, please?   Thanks!

Case closed due to no further comments received.

Hi @MartyG-RealSense,
Sincere apology for not responding soon but I was quite occupied with some other tasks. Thank you so much for addressing my issue.
Just wanted to add/request if you or RealSense team can add the instruction for Uninstalling & Upgrading the SDK (built from source) on the instruction page on installing the SDK by building from the source i.e. installation.md then it would great!
Thanks again :)


Include link to Pod Security Admission in the PodSecurityPolicy deprecation notice

Add a link to the Pod Security Admission feature, which replaces PodSecurityPolicy. Currently users who read the docs on PodSecurityPolicy may not realize what the replacement is (at least, that was the case for me). The linked blog post talks about the KEP that created Pod Security Admission, but with no direct link.

/lgtm

/label tide/merge-method-squash
/lgtm
/approve


Better for-loop code size optimization

Write for-loops normally instead of trying to manually optimize code size
This results in smaller files. It's easier to write and makes the project more approachable to newcomers who would not be familiar with the idiosyncratic coding style. It's a better use of expensive developer time to let contributors to the project focus on core issues and let the uglifyJS authors deal with the problem of minifying code
Before
$ ls -l dist/
550346 Oct 23 20:22 Chart.bundle.js
210688 Oct 23 20:22 Chart.bundle.min.js
403486 Oct 23 20:22 Chart.js
397024 Sep  9  2017 Chart.js.zip
159001 Oct 23 20:22 Chart.min.js
159001 Oct 23 20:03 Chart.orig.min.js

$ gulp size
[20:22:52] all files 56.43 kB (gzipped)

After
$ ls -l dist/
549420 Oct 23 20:24 Chart.bundle.js
210470 Oct 23 20:24 Chart.bundle.min.js
402560 Oct 23 20:24 Chart.js
397024 Sep  9  2017 Chart.js.zip
158772 Oct 23 20:24 Chart.min.js
159001 Oct 23 20:03 Chart.orig.min.js

$ gulp size
[20:24:56] all files 56.28 kB (gzipped)

Thanks for clarifying the original reason for implementing in this manner. I've fixed anywhere that was computing an expression, calling a function, etc.
The page you referenced was last updated in May 2015. StackOverflow suggests that of at least June 2016 the optimization makes no difference in Chrome:

The for loop with cached length sometimes delivered better results than the one without caching, but the difference is almost negligible, which means the engine might be already optimized to favor the standard and probably most straightforward for loop without caching

And is slower in Firefox:

"Loop, inlined code" 360,616 ops/sec ±0.27%, "Loop, cached value, inlined code" 345,786 ops/sec ±2.18% (Sic!) "Reverse loop, implicit comparison, inlined code" 322,640 ops/sec ±2.90% (!!!). Tests were executed by FF51.

One page I found suggests that using let and const rather than var is an improvement and another suggests that for-in and for-of loops are faster than standard for-loop. If we really want to optimize (I'm not sure we should), then I'd prefer these solutions

Well, like I said, it's maybe less true now on Chrome/Firefox but on some other platforms it makes a huge difference (e.g. QML). let and const will require us to integrate babel, do we really want to do that now? Same for for ... of and in that case the transpiled code is pretty ugly compare to a regular for loop.


[BE] create new blog in db

adds new blog to blogs collection in db
adds a blog field with blogName to users collections

I'll just go ahead and merge it then.


[TEVA-1295] update alert email copy

https://dfedigital.atlassian.net/browse/TEVA-1295
'You can manage your alert here.' text is not added as part of this task but will be added when dashboard is implemented

@david-mears-dfe yes i saw this change in cesi's. i need to close this PR and create another as the environment deployment is messed up for this one


[Question] Does it support namespaces

Thanks for the awesome project!
I'm thinking of transitioning from next-i18n-next to this project, but my project already is organized through namespaces.
Does the library support namespaces as well?

Thanks for asking (and sorry for late reply). I have to look at i18next namespaces first.


[Howto]: How can i run multiple projects with different configuration?

Have you already checked elsewhere?

[X] I have read the Devilbox documentation
[X] I have checked the Devilbox Troubleshooting Guide
[X] I have checked the Devilbox FAQ
[X] I have checked the Devilbox Howto
[X] I have checked the Devilbox Forum
[X] I have checked existing issues
[X] I have googled already with no luck
[ ] I have not done any of the above

What are you struggling with?
How can i run multiple projects with different configuration. if all the project are under ./data/www they will be under same php, mysql and other services. how do i seperate the .env file for each project.
for example:
project 1
php 5.6
mysql 5.5
apache 2.2
project 2:
php 7.4
mysql 5.7
apache 2.4
project 3:
php 8.1
mariadb 10.7
apache 2.4
What have you tried already?
I have tried to setup multiple devilboxes, but it won't work, becuase i have to take down the first one in order run the second one.
What is your goal?
I don't want to setup devilbox for each project (which does not work anyway). I want to keep all projects in one directory and apply different .env settings on each project or group of projects.

@wcaaan this is currently not possible. See this open issue here: https://github.com/cytopia/devilbox/issues/146

@wcaaan you can at least now run different PHP versions per project #942


docs: mention Prometheus in intro

@agardnerIT commented:
Nitpicking but: Datadog, Dynatrace, Lightstep, Honeycomb, Splunk

missing Prometheus
it should be alphabetical OR we are subtly suggesting that datadog is better than DT.
(My opinion) but we shouldn’t give free promotion. If the vendors want their name listed here, they should write a provider. By giving this list, we’re putting Honeycomb on the same footing at DT.

This PR:

Adds Prometheus to the list of data providers and arranges them in the order they were implemented for KLT
Replaced the names of other data providers with "and others"
Tweaked the prose a bit for better flow

The build error is about the link to the HPA docs.  The link works fine -- I think markdownlint has a bit of trouble to xrefs to subsections of a page


setInterval (and setTimeout) is called way more frequent than it suppose to be

Description
I was writing a page where the app counts 1000 to 0, decreasing the value by one for every second. It should be very simple to write, but to my suprise, the number dropped crazily fast.
I tested on Snack but nothing went wrong. My testing phone is Xiaomi K40 (Android 11), and this problem does keep occuring on my phone for most of the time.
There was a time I reloaded the app, and the problem suddenly disappeared. I saved the code a copy, and I rewrited the code using hooks, but some other unrelative problems occured, so I recovered the code to the copy, then the problem was shown again.
Version
0.69.6
Output of npx react-native info
info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.19043
    CPU: (6) x64 AMD Ryzen 5 3500X 6-Core Processor

    Memory: 6.84 GB / 15.94 GB
  Binaries:
    Node: 16.17.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.15.0 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK: Not Found
  IDEs:
    Android Studio: AI-213.7172.25.2113.9014738
    Visual Studio: 17.3.32804.467 (Visual Studio Community 2022)
  Languages:
    Java: Not Found
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.0.0 => 18.0.0
    react-native: 0.69.6 => 0.69.6
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
info React Native v0.70.3 is now available (your project is running on v0.69.6).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.70.3.
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.69.6.
info To upgrade, run "react-native upgrade".

Steps to reproduce

Create a expo typescript blank project
Paste the example code and run expo start
Scan the QR code and run the App

Snack, code example, screenshot, or link to a repository
import React from "react";
import { Text, View } from "react-native";

export default function App() {
  return (
    <CountdownAnimation
      onCountdownFinished={() => console.log("done!")}
    ></CountdownAnimation>
  );
}

interface CountdownAnimationProps {
  onCountdownFinished: () => void;
}

type CountdownAnimationState = {
  count: number;
};

export class CountdownAnimation extends React.Component<
  CountdownAnimationProps,
  CountdownAnimationState
> {
  constructor(props: CountdownAnimationProps) {
    super(props);
    this.state = { count: 1000 };
  }

  componentDidMount() {
    let timerID = setInterval(() => {
      if (this.state.count === 0) {
        clearInterval(timerID);
      } else {
        this.setState({ count: this.state.count - 1 });
      }
    }, 1000);
  }

  render() {
    return (
      <View
        style={{
          justifyContent: "center",
          alignItems: "center",
          flex: 1
        }}
      >
        <Text style={{ fontSize: 128 }}>{this.state.count} </Text>
      </View>
    );
  }
}

https://user-images.githubusercontent.com/17926083/195996343-48c18f61-731c-4ba7-95aa-83d083795803.mp4

Oddly, I remove Expo Go from my App and reinstall it from Play Store, the problem is gone again. (Not sure whether it will come up later again or not).

This could be related to you not clearing your setInterval when the components unmounts, which in dev mode happens a bunch of times due to Fast Refresh.
Try adding something like this to your component
componentWillUnmount() {
   clearInterval(this.timerID);
}

@StephenChips you are not cleaning up the when the component unmounts so its to be expected to be called way to many times for example in dev when react renders double or a parent component renders or when it gets hot reload.

I ran into a similar issue and cleaned up. When using 1000ms my callback function is fired every millisecond. When using 10000ms my callback is called every 10 seconds. It's very odd and there is an issue with setInterval and setTimeout with react native.

I ran into a similar issue and cleaned up. When using 1000ms my callback function is fired every millisecond. When using 10000ms my callback is called every 10 seconds. It's very odd and there is an issue with setInterval and setTimeout with react native.

Seeing the same thing - a 1000ms timer on Android fires immediately, 60000ms fires in ~60s, as expected. 1000ms works fine on iOS.

I ran into a similar issue and cleaned up. When using 1000ms my callback function is fired every millisecond. When using 10000ms my callback is called every 10 seconds. It's very odd and there is an issue with setInterval and setTimeout with react native.

Seeing the same thing - a 1000ms timer on Android fires immediately, 60000ms fires in ~60s, as expected. 1000ms works fine on iOS.

@DavidKnight-Bluescape, is this happens in a debug mode? The reason could be the differ in the time of your android device and computer.
According to the note in the docs https://reactnative.dev/docs/timers


feat(vite): new file filter option

This PR adds the ability to filter out files from the optimizer with a predicate function. It can be useful if you're using multiple frameworks alongside Qwik, and gives the ability to customize what files get passed into qwikVite.
Without this PR, other JSX frameworks do not work with Qwik, this is something we thought previously was not necessary, but it is 😅
I am currently using the build artifact in the Astro integration so that @astrojs/react can work alongside Qwik.

@thejackshelton 👏 you rock

@thejackshelton 👏 you rock

Haha this is actually code misko and I wrote a while back. The missing piece being some integration code that was what we needed. Figured I'd go ahead and merge since we both looked at it together at the time.


New command: m365 pp website webfile get

Usage
m365 pp website webfile get
Description
Gets information about the specified web file
Options

Option
Description

-i, --id <id>
The id of the web file to retrieve details for.

--websiteId [websiteId]
ID of the Power Pages website. Specify either websiteId or webName but not both.

--websiteName [websiteName]
The unique name (not the display name) of the Power Pages website. Specify either websiteId or webName but not both.

-e, --environmentName <environmentName>
The name of the environment where the Power Pages website is located.

--asAdmin
Run the command as admin and retrieve the web file for environments without explicitly assigned permissions.

Examples
Retrieve web file for the site  Contoso
m365 pp website webfile get --id 2ca3eaa5-140f-4175-8261-3272edf9f339 --websiteName Contoso --environmentName "Default-2ca3eaa5-140f-4175-8261-3272edf9f339"

Default properties
No response
Additional Info
https://learn.microsoft.com/en-us/power-apps/developer/data-platform/reference/entities/mspp_webfile

May I work on this


WIP: open a PR to see if it triggers a release

BTW I suspect this will need to be done via a fork --- I can go ahead and try this.


proposal: Go 2: generics: use operators for meta typing

The current proposal for generics is based on interfaces with added type lists. In this proposal I'd like to explore the possibility of using operators instead.
Rationale: compactness and orthogonality with interfaces.
My main argument is that generics should not allow you to do something you can already do with interfaces. For example, if interfaces can be used for meta typing you then have to decide whether to take io.Reader as a parametric type or as an argument type when implementing some function that reads data. In almost all cases it is hard to decide which option is objectivily better (if any), however the question would arise for a lot of functions. Therefore it is better not to provide the option.
Furthermore, interfaces are complicated enough as they are and deal mostly with dynamic (runtime) behavior. Overloading the interface concept to also express generic type constraints does not align very well with the Go adagium of "orthogonality" and can become confusing. I think it is therefore better to not use interfaces for generic type constrains.
Instead of using interfaces, we could use operators directly. This is compact and allows to write functions and types that can currently not be specified with intefaces (and vica versa). The drawback of this approach is that no methods can be called directly on variables of parametric types. However, that can always be alleviated by using a helper (generic) function or (generic) interface.
Proposed syntax:
func Min[T <](a T) T {} // specify a single required operator (less than)

func Max[T >](a T) T {}

func Find[T ==] (values []T) int {}  // T must be comparable on equality

func Must[T =] (result T, err error) T {  // any type can be indicated with = (or &) as all types support assignment
	if err != nil {
		panic(err)
	}
	return result
}

type Bimap[K, V ==] struct {   // K and V must both support ==
	forward map[K][V]
	reverse map[V][K]
}

type ListNode[T =] struct {   // T can be any type
	prev, next *ListNode[T]
	Value T
}

func Abs[T (<,-)] (a T) T {   // multiple required operators must be parenthesized.
	var zero T
	if a < zero {
		return zero - a
	}
	return a
}

func Abs2[T (<,(-))] (a T) T {   // unary versions of operators that also have a binary version must be parenthesized
	if a < zero {
		return -a
	}
	return a
}

func Negate[T ((-))](val T) T {   // double parens because (-) would be a list with only the binary minus operator
	return -val
}

func New[T &](value T) *T {
	return &value
}

// Deref returns the value pointed by ptr or the zero value for T if ptr is nil.
func Deref[T =](ptr *T) T {
	if ptr == nil {
		var T zero
		return zero
	}
	return *ptr
}

type Arith[T =] interface {   // a generic interface to any scalar type (can be implemented for floats, complex, big.Float,Rational etc)
	Add(T, T) T
	Sub(T, T) T
	Mul(T, T) T
	Div(T, T) T
}
func Dot[T =](a, b []T, ops Scalar[T]) T {}

One place where people want to use generics is in containers.  For a simple example, people want to be able to write a linked list package that can store values of any type without unnecessary overhead.  With the current generics design draft, that might look like https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/testdata/go2path/src/list/list.go2 .  How could that be done with this approach?

Instead of any you would use = to specify "any type" (because all types support the assignment operator). The rest stays the same:
type Element[TElem =] struct {
next, prev *Element[TElem]

  // The list to which this element belongs.
  list *List[TElem]

  // The value stored with this element.
  Value TElem
  }

For most generic types the constraint will be either = for all types or == if T is used as map key. I have included examples in my original post.

In my opinion the syntax is a bit cryptic. (-) ideally should mean the same thing as -, not to mention that the only time that a binary operator differs from a unary operator is with string (where the binary operator is defined, but not the unary operator).

func ScanSqlResult[S .](row *sql.Row) (*S, error) {   // S must support the lookup operator . and so is struct (this is useful for e.g. type safer ORM code)
This is not quite true - the . symbol is not an operator, but rather part of the Selector syntax which supports all types. Specifying that . only works for structs seems unintuitive to me.

Is there a way to write something like the Stringify function from https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-a-constraint ?

Dunno why some downvoted without giving their reasons. I upvoted for 2 reasons: the proposer gave his honest (and I believe valid) take even if eventually his proposal would be rejected; the proposed syntax is clean albeit with some drawbacks - perhaps we could use a combination of operators for default and interfaces for others?

@deanveloper
You are right about the . "operator"; I will remove the example.
Regarding the (-) syntax: First note that the use case for the unary minus operator is exotic. The only examples that I could come up with are Neg and Abs2. I considered having - imply both unary and binary but there's also the case of * which both binary multiplication and unary dereferencing operator. Because I think requiring the dereferencing operator or unary minus is so exotic the double () syntax is better than a "this implies that"  rule.  But it's debatable and there's other options as well of course such as using -., etc.

@ianlancetaylor
Note that my proposal is to explicitly not support this as Go provides interfaces already for this:
// The caller can just construct the list with items an then call Stringify
// This aligns well with other "solutions" in Go where the  programmer is instructed to just write a simple for loop
func Stringify(list []fmt.Stringer) string {
	// ...
}

Note that this version is more general than the generic Stringify that you linked to: here the items in list can be of different underlying types while in the generic version they necessarily are of the same type. So in this case, allowing generics to specify methods would lead to a less general implementation (although slightly less performant) than what you can already do with interface.
Other arguments are in the original post. Of course, a generic solution with a helper function is also possible:
func Stringify[T =](list []T, fn (val T) string) string {
	// ...
}

A slice of type []fmt.Stringer is not the same as a slice of type []T where T implements fmt.Stringer.  There only way to convert the latter slice into the former is to write a loop.  https://golang.org/doc/faq#convert_slice_of_interface
I agree that a helper function would work, but it's awkward.  That seems to me that it might be a significant drawback to this proposal.  Perhaps I am mistaken.

@ianlancetaylor
I may also be mistaken of course, I just hope to add to the discussion and understanding of what generics in Go should do.
What I meant is that the abstract functionality provided by interfaces is inherently more powerful than that of a generic list []T:
func Archive1(items io.Reader...) {
	// ...
}

buf := &bytes.Bufffer{}
file, _ := os.Open(...)

Archive1(buf, file)	// ok

func Archive2[T io.Reader](items T...) {
	// ...
}
Archive2(buf, file)	// invalid

Interfaces are more powerful than generics in most cases because they can operate on heterogeneous types.
Therefore I think the interface version Archive1 should be preferred over Archive2[T]. The argument for Archive2 just to save writing a for loop for the uncommon case where []T needs to be converted to []io.Reader is not too convincing.
There are exceptions where using []T is better, however a solution with a helper function is not awkward but quite natural (and quite common):
func SortList[T =](list []T, less func(a, b T) bool) {
	// ...
}

This more succinct and more direct than:
type Lesser[T] interface {
	Less(other T) int // should return -1 if less than, 0 on equal and 1 if greater than
}

func SortList[T Lesser[T]](list T[]) {
	...
}

Which requires defining an extra interface type and also requires the addition of Less as a method on T. Other examples are Map/Reduce. Of course the first example can be written in the current proposal; the point is that you don't need an interface meta type here.

Just to be clear, it seems to me that the current generics design draft permits writing any kind of code that is permitted by this proposal, albeit with a different syntax.  The current design draft also permits writing other kinds of code, that cannot be written with this proposal.  Would you agree with that?

How well would this support something like a Graph structure, where there is a relationship between the type parameters?
type Node[TEdge =] interface {
    Edges() []TEdge
}
type Edge[TNode =] interface {
    Nodes() (from, to TNode)
}

type Graph[TNode ??, TEdge ??] struct { ... }

There doesn't seem to be a good way to explain the relationship between TNode and TEdge in the Graph interface from what I can tell.
As for some feedback, I think this proposal offers a solution which really is trying to accomplish adding "operator interfaces" (allowing interfaces to describe operations on types), but doing it by tightly coupling it with the idea of type parameterization, when they are actually two entirely separate concepts. Because this proposal couples these ideas together, it would make it very hard to add more features to either of these concepts individually.
The current generics draft introduces these two concepts as two separate ideas. "Operator interfaces" are instead introduced as type lists, and type parameterization is introduced as such. For instance, consider the function func Abs(i Integer) uint64. There are no relationships between the parameters/return values, so I shouldn't need to use type parameterization. All I want to do is make sure that I can compare i to zero, and negate i if needed. However in this proposal, I would instead do func Abs[T (<,(-))](i T) uint64, which in my eyes is a bit of a cryptic syntax, as well as forcing me into using type parameterization where I wouldn't need it.

@deanveloper
Regarding the graph structure, that's not supported (by intention), because you can use functions or interface already. I think a simpler approaches that provide the same functionality is better because it is so much shorter, something like:
// ShortestPath returns the shortest path between two nodes.
// Edges must the nodes that can be reached from each node.
func ShortestPath[Node ==](from, to Node, edges func(Node) []Node) []Node {
	// ...
}

Regarding your feedback. I am not trying to accomplish "operator interfaces" I think (I am not entirely sure want you mean with it). I started out by looking at what the minimal possible thing is that is needed to support T in any type: thats assignability ('any' currently) and comparison (on equality, for map keys)). With those you can express any generic type (except functions and methods).  These are expressed in Go using = and == which are also short and so are the most direct way of expressing want you need. The next thing is Min, Max functions, etc. These can also easily be supported by allowing any operator instead of just = and ==, and also a list of operators. This is all still orthogonal to current expressibility in Go.  If you want to be able to call methods on T, there's interfaces and functions already. Yes, this excludes examples like the graph example, but I couldn't find any convincing example for which it would be needed and for which there's no alternative with helper functions or generics. Maybe that's indeed incorrect, I'd love to see a convincing country example (that does not resemble C++ Boost or STL implementation).
Using operators also does not need to make it very hard to add more features. For example you could add syntax to the language that give a name to the meta type constraint:
meta E ==  // any type that implements ==
meta Arith (+,-,*,/)

func Dot[T Arith]()

I am not saying that we should; it is not part of my proposal. Just an example of how it could be extended. If we want you can extend that and allow interfaces as well:
meta S fmt.Stringer // any type that implements the methods in fmt.Stringer
meta S2 (fmt.Stringer,+,-) //  any type that implements the methods in fmt.Stringer and supports +,-

Although I think this is not a good idea, for reasons explained earlier. But it's not hard to extend the syntax. In fact, I think that if you want to allow to call methods on T, you should also be able to access fields etc.

@ianlancetaylor

Just to be clear, it seems to me that the current generics design draft permits writing any kind of code that is permitted by this proposal, albeit with a different syntax.

Almost, but this proposal does not introduce 'any', 'comparable', type lists in interfaces and a multitude of additional rules on interfaces (can't call method on type list types, comparable on being able to use as normal interface type, etc etc). It also does not convolute the concept of interface.
Almost, because I think my proposal would allow to make functions that operate on untyped constants which could be useful:
func Max[T <](a, b T) T
var my float64 = Max(math.Pi, math.E)   // Pi and E are not converted to float64 by Max

That's not possible with the current generics design without additional syntax. I also think that allowing parametrized methods are easier to allow, but I am not sure.

The current design draft also permits writing other kinds of code, that cannot be written with this proposal. Would you agree with that?

Yes, and vice versa (see above). I am not sure it is fruitful to compare proposals on syntax that they are being able to generate though. On a type safety level they can express the same functionality.

On a type safety level they can express the same functionality.

That is exactly what I am questioning.  It seems to me that the current generics design draft permits expressing functionality that this proposal does not permit.  This is not a question of syntax, it's a question of semantics.  Specifically I am thinking about examples like Stringify or the Graph examples mentioned above.  Yes, of course you can write those in other ways by passing function closures or something.  I believe that my basic point remains true: the design draft permits expression functionality that this proposal does not.  That doesn't mean that this proposal is bad or wrong.  I'm just trying to precisely clarify what is being suggested here.
The untyped Max is an interesting example but it would require additional language mechanisms that don't currently exist.  Right now untyped constants can only be used in constant expressions.  An untyped Max would also require untyped variables.  It's not immediately clear to me how that would work.  However it works, it appears that any implementation would absolutely require a specific implementation--monomorphization aka stenciling, and it would also require complete inlining of any function instantiated with untyped values.  At least, I don't immediately see how to do it any other way.

@ianlancetaylor
Well, your basic point is true of course but it's a bit of a moot point because I stated that exactly in my proposal:

My main argument is that generics should not allow you to do something you can already do with interfaces.

You may disagree with that of course (and to be honest I would be very interested in opinions/convincing examples from anyone, I could be very wrong).
You are also absolutely right that you can't do Stringify[T](list []T) exactly with current go or with this proposal. But the majority of applications of interfaces are things linke iotuil.ReadAll(r io.Reader). But stating only that makes it seem that you flag this proposal as "not a good idea" just because of this, and it makes me think that my main point is missed.
Of course I might be very wrong and the use case for the Graph example and the Stringify example prove to be strong use cases. However it seem to me they are exotic wrt to at least the Go standard library. Especially the Graph example looks overly complex for what it achieves? Do we want that? Do we want people to write C++ Boost like libraries in Go? And if we allow method calls, what about calling free functions on T and accessing fields? Why the cut-off at methods? I think a convincing example to be able to access fields in generic code is the Sibling function that I mentioned earlier. This function cannot be written with the current generic proposal (nor the one in this issue).
// package bintree

func Sibling[Node ??](node *Node) *Node {
   if node.Parent == nil {
        return nil
   }
  if node.Parent.Left == node {
       return node.Right
  }
  return node.Left
}
func SearchDepthFirst[Node ??](node *Node, fn (*Node) bool( { ...}
// etc

This example convinces me because writing getter/setters accessor for every field seems silly if used in generic code especially combined with perfomance arguments.
Maybe this proposal is not a good idea at all. It could also be that's its a matter of taste and people just like to write generic code instead of using interfaces.  I hope you and others will consider my arguments against overloading interfaces with applications to generics. I am a bit worried for fancy coding syndrome wrt to generics and the extra design choice you would have to make when writing a functions like iotuil.ReadAll(r io.Reader), i.e. take [T io.Reader] or (r io.Reader) . Maybe that worry is ungrounded.
Thank you for your notes on the Max wrt untyped constants. I am quite out of my depth on that area, but I agree inlining is indeed looks like to only way to realistically do it.

My main argument is that generics should not allow you to do something you can already do with interfaces.

You may disagree with that of course (and to be honest I would be very interested in opinions/convincing examples from anyone, I could be very wrong).

I would agree with a slightly different statement: there is no reason to use generics to do something that you can already do with interfaces.  But you seem to be saying that it is important that it should not be possible to use generics do things that can already be done with interfaces.  I don't agree with that as a goal.  There is no reason that generics should permit code that can already be written with interfaces.  But I see no reason to go out of our way to ensure that generics cannot be used to write code that can already be written with interfaces.  Among the important things about generics is that they are clear and straightforward, and that they are as orthogonal as possible to other language constructs.  Ensuring that they cannot be used where interfaces can be used is not a priority.

Of course I might be very wrong and the use case for the Graph example and the Stringify example prove to be strong use cases. However it seem to me they are exotic wrt to at least the Go standard library.

This is close to a circular argument.  The Go standard library was written in a language that doesn't have generics, so naturally it doesn't use generics.  When we present a use case in which the Go standard library could use generics, it doesn't make a lot of sense to say that it doesn't fit the Go standard library because the Go standard library doesn't use generics.  The whole point is to change the Go standard library to use generics.  Now, of course, it may be a bad idea for other reasons.  But this reason isn't one of them.

And if we allow method calls, what about calling free functions on T and accessing fields? Why the cut-off at methods?

You can already call free functions on variables of type T.  Perhaps I misunderstand your point.
  I'm not opposed to a generics proposal that permits accessing fields with known names and types.  I agree that the current design draft doesn't support that.
I agree that your Sibling example can't be written using the generics design draft.  But I'm not clear on why that matters.  That kind of code is only useful if there are multiple different data structures with Parent, Left, and Right fields.  If we have generics, it seems to me more likely that people would write a generic data structure with those fields.  Or if we are looking for something more like the Graph example, it doesn't seem unreasonable to require Parent, Left, and Right methods.

Using your proposal, how would you express a generic function that increments a generic numeric integer argument by a given constant value, say 1234, and then returns that incremented value? Specifically, how would you express that you can't provide a byte argument because 1234 overflows byte? This is one of the problems one will need to address when constraining generic functions with operators, at least for Go.
Along similar lines, if one writes a generic function that uses * (multiplication) and down the road it turns out that the implementation can be made more efficient via a clever use of + (addition), would it be possible to change the implementation even if one had not foreseen the use of +; or would it require an API change?

@griesemer

Using your proposal, how would you express a generic function that increments a generic numeric integer argument by a given constant value, say 1234, and then returns that incremented value? Specifically, how would you express that you can't provide a byte argument because 1234 overflows byte?

func Inc[T +](a, b T) T {
	return a + b
}

func main() {
	var q byte
	const a = 1234
	Inc(q, 1234) // invalid: constant 1234 overflows byte
	Inc(q, a) // invalid: constant 1234 overflows byte
}

Maybe I am misinterpreting your question though: the code above expresses your requirement of "not being able to pass 1234 as a byte const",  however it did not need to use type constraints for it (nor couldn't). It's already checked by Go on the call site.
(Note: I am assuming here that T=byte can be inferred from q with a being untyped. If that is problematic Inc[byte] must be used at the call site, but it's not related to your question I think. )

Along similar lines, if one writes a generic function that uses * (multiplication) and down the road it turns out that the implementation can be made more efficient via a clever use of + (addition), would it be possible to change the implementation even if one had not foreseen the use of +; or would it require an API change?

No, it would require an api change.  If the api was SomeFunc[T *]() it will need to be changed to SomeFunc[T +](). I am not sure why that would matter that much though, all types that support * also support +.

@ianlancetaylor

Among the important things about generics is that they are clear and straightforward, and that they are as orthogonal as possible to other language constructs.

I agree, that's the reason I wrote this proposal. Would you agree that the current generic proposal is not as orthogonal as possible to other language constructs, especially with respect to interfaces?

Would you agree that the current generic proposal is not as orthogonal as possible to other language constructs, especially with respect to interfaces?
I am still confused about how the current generics draft is not orthogonal to interfaces. The draft integrates with interfaces, but any features that are provided by interfaces are provided by interfaces, not parametric types.

@deanveloper
Maybe the confusion arises because of different understandings of "orthogonality".
This is how I see it: with the current generics proposal you can write:
type interface Reader {
	Read(p []byte) (int, error)
}

func ReadAll1(r Reader) ([]bytes, error) {
	// ..
}

// and

func ReadAll2[T Reader](r T) ([]bytes, error) {
	// ..
}

ReadAll1 and ReadAll2 achieve the same thing. To me that makes it "less orthogonal". Btw, which one would you prefer? Which one would you use or recommend to use?  Which one is better when? That is a question that will come up very often, I think. I can be wrong of course, but it worries me a bit (partly because my feeling is people will default to the generics version because "it is faster" resulting in a lot of unnecessary generic packages). I hope that clarifies it somewhat.

ReadAll1 and ReadAll2 achieve the same thing. To me that makes it "less orthogonal".

I don't think that makes it less orthogonal. It hasn't even replaced the Reader interface, it just moved it. I feel like that'd be similar to saying that parentheses aren't orthogonal because (0) and 0 mean the same thing. We have used one feature of the language (parentheses) needlessly to wrap the other feature of the language (constants). This doesn't mean that parentheses aren't orthogonal, because they do something entirely different than numbers do.

Btw, which one would you prefer?

The one that uses fewer features. I obviously prefer 0 to (0), just as I prefer func ReadAll1(r Reader) ... over func ReadAll2[T Reader](r T) ....

Which one would you use or recommend to use?

See previous

Which one is better when?

Use the fewest features that you need. If you don't need parentheses, it's not good to use them as they can make code look cluttered and hard to understand. However, there are times when you need parentheses, and they are good to use for those times.

partly because my feeling is people will default to the generics version because "it is faster" resulting in a lot of unnecessary generic packages

That is a real concern. Generic bloat is something that's seen in a lot of languages and it makes code harder to read. I've used Rust for quite some time, and Rust enjoys using generic parameters for both variable lifetimes and parametric types, and it can honestly be quite infuriating trying to work out what code is doing. However, I think that Go's implementation of generics is very simple because the Go type system is simple, so there is no need for things like doSomeCloning<T extends Cloneable<? super T>>(t T) which is one of my big gripes with generics.
I think one of the big takeaways is that just because things like func ReadAll[T Reader](t T) ... are possible doesn't mean that they will happen, just as we see that unneeded parentheses don't happen in practice when they aren't needed (or at least aren't helpful, sometimes redundant parentheses can help with readability of course).

Regarding your reply: Yes, I indeed meant
func Inc[T +](a T) T {
	return a + 1234
}

Basically, what you are saying is that one cannot type-check this function independently from a call site (which may not yet exist if this is a library function). It's not just bytes. What if the constant is 1000000? What if it is negative and we have uint types? Etc.
Also, changing an implementation such that it uses + rather than * (or - rather than +!) is not unusual and shouldn't require an API change. It also shouldn't require the author to anticipate such a change and require all "possibly needed operators" to be listed in the API.
These are some of the reasons why the current generics design draft doesn't try to use operator methods in its constraints. It seems that your proposal has all the problems of operator methods.

Why does no one mention the relation to operator functions? My impression is that supporting operator functions solves the issue generally. One can simply put the operator functions into a constraint. For instance:
type Int int

func NewRandInt() Int {
    return rand.Intn(100)
}

func (a Int) + (b Int) Int {
    return int(a) + int(b)
}

type Additive [T any] interface {
    T + (T) T // + operator function
}

func Add[T Additive](a ...T) T {
    switch l := len(a); l {
    case 0:
        return 0
    case 1:
        return a[0]
    default:
        var sum T
        for i := 0; i < l; i++ {
            sum = sum + a[i] // VALID   because +  operator function is in the Additive constraint
            // sum += a[i]   // INVALID because += operator function is not in the Additive constraint
        }
        return sum
    }
}

// Usage

a := NewRandInt()
b := NewRandInt()
Add(a, b) // INVALID: Add[Int](a, b), Int implementes + operator function

@changkun You mean "operator methods". But operator methods have the problem discussed here.

@griesemer I am so sorry that I somehow missed your message directly above mine. Thanks for pointing out. But I do have some further questions:

one cannot type-check this function independently from a call site
Why operators become an issue in type-checking when they are treated as method names eventually (type Int implements + method, equivalent to type Int implements Add method)?

changing an implementation such that it uses + rather than * (or - rather than +!) is not unusual and shouldn't require an API change
A generic implementation can only use methods from a constraint. Why shouldn't we need an API change? Could you maybe give some more detailed examples of the problem?

It also shouldn't require the author to anticipate such a change and require all "possibly needed operators" to be listed in the API.
"possibly needed operators" seems equivalent to "possibly needed methods," why are they be treated differently?

The issue is not about + vs Add, the problem is related to the use of constants in the generic code. If the API says  the argument type needs to provide + (or Add, same thing), and the type byte is provided, the API is satisfied. Yet, if inside the generic function I add the value 1024 to a value of that generic type (in this case byte) what should happen? In regular Go, I cannot write x + 1024 if x is of byte type because 1024 overflows byte's range. That is, if we want to preserve regular Go behavior for generic functions, we need to express somehow in the API that the argument type not only supports +, but also that it must be "big enough" to handle the constant 1024. Otherwise we cannot type-check the function independent of the invocation because we don't have any information about the type parameter besides that it supports +.
Regarding the * vs + problem: If I write a generic function
func double[T *](x T) T { return 2*x }

and later decide that x+x runs faster on my machine than 2*x, then I will need to change the function signature:
func double[T +](x T) T { return x+x }

even though the effect of the function didn't change. Sometimes such changes come about from refactoring. We don't want to need the API to change in such cases (and possibly break client code).
The current generics design draft doesn't have any of these problems because no operators are specified, only types (in an interface's type list). Given
func double[T interface{type int}] { return 2*x }

one can use any operation defined on an int type inside the double function. I can also use any constant that is accepted by an int type. Etc.

PS: Worse, what if the generic function requires + (or Add) in the signature, the function internally does x + 1 (works with any numeric type) and then the type argument is string?

we cannot type-check the function independent of the invocation because we don't have any information about the type parameter besides that it supports +.

Indeed this is an issue using operators for meta typing but still seems fine in operator methods because all applicable types are declared in the constraint.

and later decide that x+x runs faster on my machine than 2*x, then I will need to change the function signature

This seems natural, if the implementer decides to use + other than *, it means the implementer is expecting a new method from its constraint. Besides, such a change will only appear in custom types.

what if the generic function requires + (or Add) in the signature, the function internally does x + 1 (works with any numeric type) and then the type argument is string?

OK. This is a fair point because it will leads to the discussion that Go has no function overloading and SFINAE support eventually.

Would you agree that the current generic proposal is not as orthogonal as possible to other language constructs, especially with respect to interfaces?

In a programming language orthogonality doesn't mean that there is only one way to do something.  It means that there are no restrictions on how different concepts can be combined.  See https://en.wikipedia.org/wiki/Orthogonality_(programming) .
That said, Go is not a perfectly orthogonal language.  And the fact that in the current design draft interface types with type lists can only be used as type constraints is a failure in orthogonality.  But the fact that interface types in general can be used as type constraints is, I think, reasonably orthogonal.  We are adding another layer of meaning to interface types, but it is a layer consistent with what interface types already mean.

Let me add something about the larger point here.  In Go, interface types are already a form of generics.  I mentioned that https://blog.golang.org/why-generics, and I explained why I don't think that is sufficient.  Perhaps that will help explain why I think that the facts that you are pointing out are not a significant problem with the generics design draft.  Thanks.

@griesemer

If the API says the argument type needs to provide + (or Add, same thing), and the type byte is provided, the API is satisfied. Yet, if inside the generic function I add the value 1024 to a value of that generic type (in this case byte) what should happen?

I fully understand the concern. Let me try to address them.
To use numerical constants, you must require at least (+,-); to use negative constants requires at least (+,-,(-)).
Regarding the 1024/1000000 example: what I meant was even under T (-,+,(-)), the allowed constant range that you can use is [-127,127] , because this is guaranteed to fit in any integer (likewise [0,255] for R (-,+)).  To me that makes sense: writing a function AddMillion that guarantees no overflow would be not possible to express for the reason that T is abstract and so only 127 can be maximally guaranteed for T for the API. However, it can be still written if the guarantee  is removed and just documented:
// AddMillion adds 10^6 to a. If T cannot store millions, the result may be incorrect.
func AddMillion[T (-,+,*)](a T) T {
	var ten T = 10 // valid becaulse < 128

	thousand := ten * ten * ten
	million := thousand * thousand
	return a + million
}

I don't think this is entirely unreasonable: many functions say something like 'if value is not a pointer the function panics`, etc.
(For floats there is no issue I think (not sure) because var m float64 = math.Pi is currently valid even though float64 cannot represent math.Pi exactly?).
That being said, another solution is of course to allow both (or either) operators and basic types as constraints. func MyC[T (complex64,complex128)](). I am cheating here because it's not part of my proposal, but maybe a logical and useful correction.  The basic type is also allowed to be the underlying type of T.
Please note that I don't know all the details of Go, although I try to, and so there may be more concerns that I am no aware of. Thanks for the explanations.

@ianlancetaylor
Thanks for the links and the explanations. My wording and use of "orthogonality" maybe didn't help. Please don't think I am just trying to bash the current proposal.
I kindly ask you to help me with the following worry that I have. If you have addressed it already somewhere, feel free to just provide a link.

In Go, interface types are already a form of generics.

I agree and it was the basis for me to write my proposal. My main worry is this:
type interface Reader {
	Read(p []byte) (int, error)
}

func ReadAll1(r Reader) ([]bytes, error) {
	// ..
}

// and

func ReadAll2[T Reader](r T) ([]bytes, error) {
	// ..
}

I honestly don't know which would be better or how to chose which version to write. Yet, I write these kinds of functions quite often. So it adds a design question (that I don't know the answer to) to my daily work. I didn't have this question before. Now I have it, and I don't know the answer. I will default to the interface version, but many others may uses the generic version. That would make their code harder to read for me and vice versa.
The question is: can you explain me which one to chose here? (And why?). That would certainly take away my concerns. I have some other concerns, like the Graph example being too clever, that might be unjustified, but the above is my main concern.

@markusheukelom This is a great question. We absolutely need to develop good conventions and "best practices" around the use of generics.
I'll try to answer for your specific example: I believe in this case ReadAll1 (no generics) is the correct choice because of the following reasons:

There is no improvement in static type safety at the call site with the generic version: The results are fixed (don't depend on the argument type), both for the ReadAllX functions and the Read method. The provided reader may be nil in the ReadAll1 case which might lead to a panic inside that function, but note that ReadAll2 could be instantiated with a pointer or interface type, too, and then have the same problem.

There is (likely) no improvement in memory layout/use with the generic version: There is a single reader to pass, and while it may need to be packed into an interface, that cost is minimal.

There is (likely) no improvement in performance with the generic version: This makes some assumptions about the cost of a Read, but its likely that the cost of performing the Read dwarfs the cost of making the Read method call via the interface compared to having a (possibly) direct call of Read in the generic version.

On the other hand, there is a cost of having a generic version for each type of Reader, depending on how the compiler translates this code.
(Note, this specific situation may be a case where a compiler might choose to implement the generic version like the non-generic version.)
In summary, if the generic version doesn't improve the code along the axes of static type safety, memory use, and performance, choose the non-generic version.
Here's another way of looking at this: Generics are essentially a "glorified" version of macros. Would you use a macro in this case (because it might give you a significant benefit)? I think the answer would be a clear "no".

@griesemer
Thanks for this. I believe the arguments you provide would actually slightly favor the generics ReadAll version:

There is no improvement in static type safety at the call site with the generic version: The results are fixed (don't depend on the argument type), both for the ReadAllX functions and the Read method. The provided reader may be nil in the ReadAll1 case which might lead to a panic inside that function, but note that ReadAll2 could be instantiated with a pointer or interface type, too, and then have the same problem.

This argument seems void as it can be used for both versions.

There is (likely) no improvement in memory layout/use with the generic version: There is a single reader to pass, and while it may need to be packed into an interface, that cost is minimal.

This actually says that the generic version has  possibly (although unlikely) better memory layout/use, and has zero packing costs (because there is no packing), while the interface version would always has non-zero packing costs (even if minimal).
Plus, as you say lower in your post, the compiler can always choose to implement with the non-generic version if it wants. So this seems to favor the use of the generics version.

There is (likely) no improvement in performance with the generic version: This makes some assumptions about the cost of a Read, but its likely that the cost of performing the Read dwarfs the cost of making the Read method call via the interface compared to having a (possibly) direct call of Read in the generic version.

This actually says that the generic version has potential improvement in performance (although unlikely), and the non-generic version is potentially (although not likely) slower.  But hey it doesn't matter: the compiler can always choose to implement with the non-generic version if deemed better. So the programmer should just always use the generic version.

I would personally add the argument that the non-generic version is far more readable and therefore outweighs the unlikely added costs.  Maybe that tips the scale towards the interface version, at least for some people, I don't know. In either case, it's very likely that a schism will develop under go programmers.
(Btw I do believe I have a possibly good argument for why Stringify should not be generic: the interface version has the added benefit that it works on lists of heterogeneous underlying types. Maybe this is something of interest to add to the "best practices" section. It has the drawback that you can't use it directly with []T (where T satisfies fmt.Stringer), but you can use a simple for loop in that case if needed.)

@griesemer

Here's another way of looking at this: Generics are essentially a "glorified" version of macros. Would you use a macro in this case (because it might give you a significant benefit)? I think the answer would be a clear "no".

I honestly don't know if I would. I don't think so, no. Well maybe I would because the compiler might in the future be better able to optimise my code.  At least I won't lock out that opportunity. I don't know really. At least currently I don't have to think about this or make a decision.

Generic features tend to add type complexity - generally, generic code is significantly more complicated to understand due to the extra abstraction. If you doubt that I encourage you to decipher some of the generic pieces of code submitted with some of the issues against the prototype.
Because of that, generic features should be used when all else fails; i.e., it's either not possible to write the code without it, it's massively slower, or it's significantly less type safe. I fail to see how that is the case with your specific question. You're of course free to code as you please, but personally, I'd go with the simpler solution that does the same thing.

(...) generic features should be used when all else fails

I agree. And I certainly agree with you in case of the ReadAll (On second thought I was exaggerating a bit).
I was voicing what I except people will use as "excuse" to still use generics, as the arguments I gave have been used for the use of "template for everything" in for example libraries for C++. (Sorry for referencing other languages, I have tried not to for as long as possible).
Keep in mind that there are many programmers who use you Go on an intermittent basis (other microservices might be written in Kotlin or Rust), or are learning Go on the side coming from Java/C/C++. They will know templates/macros, but the dynamic interface concept requires some more effort to fully understand (think of nil and type assertion syntax etc). Therefore I believe they will be inclined to use the generics version, especially because it leaves open the opportunities for optimisation by the compiler. To them the interface version might be harder to understand "with everything that's going on at runtime". In the end, the results are fixed so both work sort of equally well.
Of course if you think this will certainly not be an issue, I'll follow your lead.
Just to be absolutely sure, I do think generics are very useful (even in the current proposal). It would allow the containers packages to be type safe and allows for many other very useful stuff. The only thing that concerns me is that I personally probably don't ever need a way to call methods on T, because I have runtime interfaces, I therefore believed a simpler first like the operator list in this proposal is worth exploring. That has be done by now, of course.
Thanks a lot for taking the time and effort to listen to the community.

Thanks for the clarification and bringing in the perspective of people that might be new to Go. That's certainly something to consider, especially if we want to establish a "best practices" document.
I agree that where interfaces work great now, generics are not needed. It's really situations where interfaces would be extremely cumbersome (because they need to model operators, or because we need extra type assertions) where generics should be considered. When you look at the examples in the design draft, it is noteworthy that most examples actually use constraints with type lists because we want to use operators in a generic way.
But I think it would be too restrictive to drop the ability to require methods in constraints, which is what your proposal essentially does.
(FWIW, the shortcomings I brought up earlier about problems with constants etc. could be addressed by making the constraint for a type parameter a type list. Or in other words, if we removed the ability to specify methods on constraints and only permitted type lists - and adjusted the syntax adequately - we'd arrive at the same place where you are with this proposal.)

(FWIW, the shortcomings I brought up earlier about problems with constants etc. could be addressed by making the constraint for a type parameter a type list. Or in other words, if we removed the ability to specify methods on constraints and only permitted type lists - and adjusted the syntax adequately - we'd arrive at the same place where you are with this proposal.)

Yes, that's true, although you'd still need the special comparable identifier.
Would it be worth considering using just = and == instead of interface{}/any and comparable? I think that 95% of real world generics would use either of these two constraints so it sort of make sense to make that use case as direct and short as possible to express. The other 5% like math.Min/Max can use the interface with types lists or method for its constraint. It would also avoid introducing the comparable/any special identifiers. (I find my self naturally using T = and T == when toying around with generics because of its directness. Maybe try it for a bit).

Once you accept that a type constraint is an interface type, then to me it makes sense for the two special cases to also be interface types.  So your suggestion is sort of like saying that = and == could be names for interface types, but to me that seems a bit weird.

Ha, yes I agree that it would be certainly weird to say = and == are names for interfaces. I just meant to say instead of two special interface identifiers (any and comparable), let's do two special case constraints = and == and then custom constraints are via interfaces. Maybe that's still weird of course, but it saves a lot of typing and it nicely pops out in the already complex syntax with generics. Of course, I am completely biased.
Btw, I see the point that any would make the other use of interface{} also visually cleaner, so that has certainly that benefit. (On the other hand, the currently valid type any = interface{} has not attracted that much use.)

Out of curiosity, comparable in the current proposal was certainly not meant as a an special interface right? because this code certainly doesn't make sense (to me):
func MyFunc(a, b comparable) bool {
     return a == b
}

I understood comparable to be a special type constraint (it is also named this in the proposal). (I meant == in the same way). I am still left a bit confused though:
type My interface {
    comparable
    fmt.Stringer
}

func A[T My](a, b T) // valid
func B(b, b My) // valid??  probably not?

So this probably means that not all interfaces can be used as function argument types?

In the current generics design draft comparable is only permitted as a type constraint.  But I think it would be a very natural extension to permit comparable to be used as an ordinary type.  A value of any comparable type could be assigned to a value of type comparable.
If we did permit that then your func B(a, b My) example would be valid.

I see. So the comparable would work like an interface{}, but you couldn't assign values like maps, slices and function to them (and struct containing these). Calls like MyFunc("go", 2.0) (different types) are just fine but will always return false (as per the rules for interface).
I understand now that you see "comparable" as a property of a type instead of an operator between typed values (although it is defined like that for an interface). That might make sense indeed for a strictly typed language. It feels a bit weird to me that both these function would compile with out problem:
func MyFunc1(a, b comparable) bool {
     return a == b
}
func MyFunc2(a, b interface{}) bool {
     return a == b
}

In while in contrast, these don't:
func MyFunc3(a fmt.Stringer) string {
     return a.String()
}
func MyFunc4(a, fmt.Stringer) bool {
     return a.String() // invalid
}

Maybe it just something to get used to as a special case.

There is a difference between MyFunc1 and MyFunc2, of course: MyFunc2 might panic, but MyFunc1 never will.

@markusheukelom Presumably you meant func MyFunc4(a interface{}) string.

Thanks for the suggestion.  We're going to move forward with the current generics design draft, at least for now (https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md).
This is a likely decline. We can revisit that decision if the current design draft is not adopted. Leaving open for four weeks for final comments.

No further comments.