Thanks Ian. Setting "PreferredGPU" to "Software" solved it.

Btw, I did not see anything wrong in the Preferences dialog

It looks like it is more than Manipulate that is affected by the GPU setup, in 12.3.

I have two PC's with Mathematica 12.3. I will label them as A and B:

A. Has an Intel CPU with integrated GPU. It had the Manipulate problem, fixed by the "Software" workaround as discussed.

B. Has an AMD CPU with Radeon GPU. Manipulate works fine out of the box, without need for any workaround.

The new feature of auto replacements, replacing [[ with \[LeftDoubleBracket] etc, works fine on B. But on A there are no replacements done. Not even the familiar -> \[Rule] or :>\[RuleDelayed]

I will take this up with Technical Support.

Perhaps this might be useful somehow: https://redmine.wolfram.com

We have been aware of this issue for quite some time. I cannot give any estimate on a time frame for a fix, though.

I completely agree with this statement. The idea of a development cycle for just fixing bugs like it was done in 12.1.1. was great. Hopefully it will also be done in the future. But as far as I know it is unfortunately not planned for 12.2.

It is also a big problem for a user that there is no clear time frame when a bug will be fixed. It could be 3 month when you are lucky, three years or probably never. For some issues it might not be easy and thats understandable but for regression bugs it is not acceptable. Regressions should be fixed short term. Waiting a full development cycle which can last almost a year is simply too long. And then it is by far not clear if the issue gets fixed. If Wolfram wants to get a foot in the enterprise market for production use (Wolfram Engine, Application Server, ...) in my opinion thats absolutely necessary. I wouldn‘t take the risk and bet on a tool for critical applications when there is no clear roadmap for bug fixing. Matlab for example release a major version twice a year and a bug fix update every month. Another example is Visual Studio with regular bug fix updates.

I know that a lot of stuff has been fixed in 12.2 and that there is on going effort in that direction which is highly appreciated. But you confirmed my posting by this:

I found that over time more than 30% of the bugs from Integrate were apparently fixed. This can happen due to continued code overhaul wherein "collateral damage repair" occurs (one bug fix actually fixing more than one problem, with the developer unaware of this).

That is exactly the problem I am talking about. Depending on getting a bug fixed over time by „accident“ is at least in enterprise deployment not acceptable. I am explicitly not talking about some edge cases in mathematical functions which are not supported and you can discuss if it is a bug or a feature. I am mainly talking about examples in the documentation which are not working (there some long standing issues reported multiple times, eg. FindMaximumFlow), functions silently giving wrong results (eg. Batch Prediction for Classify with certain methods, ...), functions which are just not working for real world use cases (I am aware that this can end again in a „is it a bug or feature“ argumentation but often it is pretty obvious) and regressions, which occur in a new version and do not get a high enough priority assigned for being fixed in a reasonable time frame.

I am also excited for new features being added but I am also pretty sure that a lot of long time users of Mathematica would appreciate focusing on polishing and bug fixing instead of new features for at least a few development cycles and in no way the future is being sacrificed for the present by this. Indeed I think exactly the opposite would happen as I know users which canceled their subscription for issues not getting corrected over multiple releases. What is the benefit of a new feature which is put in and therefore breaks stuff that already worked? Such things are actually very frustrating. And as I said before: for production deployment in enterprise applications there has to be some kind of a more predictable roadmap after an issue has been reported when a fix will be available.

Hi Daniel, while I understand your point, I should point out that what we and many end users here are referring to are the longstanding issues that are overdue. Take for instance the case of FindMaximumFlow. I think for the past four years or so at least three bug reports were filed by myself alone, hoping that it might get fixed in the next update. It just never gets fixed.

The problem is that the bugs are not weeded out quickly and a lot of bug-baggage has built up over the years. From the user's perspective this can be seen (misconstrued) as Wolfram being nonchalant about longstanding bugs.

Don't you consider that bug in FindMaximumFlow and many others functions should be dealt with irrespective whether the enterprise users need it or not. The function is important for many people doing research or working with graphs and networks. Besides the inclusion of the function in the language itself mandates that any bugs should be sorted out, especially ones that are over 5 years old. A bug is a bug and needs to be fixed to maintain the userbase.

Ok I agree with your point, sometimes it may not be obvious that a particular issue is a bug or an intended feature. However, I don't agree on the workaround part. A workaround should be temporary in my opinion. If say algorithm A or a built in Function A does not work and algorithm B or a composition of other builtin functions is a workaround, then still an effort should be made to make 'A' work. Why? Because Mathematica is an expressive language and should allow all possible ways to work.

FindMaximumFlow type functionality exists elsewhere and there are cookbook procedures for it. Even the Wikipedia entry for Maximum flow problems has listed more than 10 published algorithms for solving such problems. Plus there is a section on 'Maximum Flow with vertex capacities' (which is the buggy part of the function in Mathematica) which leads me to believe that there are established procedures for solving these problems. An open source implementation can be translated for a fix.

Hi Ali,

Thank you for bringing this issue to our attention. We do in fact check documentation examples before a release. However, things do sometimes get missed from time to time, or a fix was not ready in time.

Please note that the Wolfram Language is highly interconnected. Many functions internally use other WL functions as part of their implementation, or share a codebase with several related functions. So even though a particular function did not get a specific update in a release, something it depends on might have been changed.

Another case when documentation examples are broken is Locator with option AutoAction set to True. The documentation example works in 10.4 but not in 11.3, 12.0, 12.1 or 12.2.

There is a change between 12.1 and 12.2, but only for the worse. In 12.1 the locator with AutoAction can be moved if you click on it and drag. But in 12.2 it will not move at all, clicked or not.