LinalgRefactor - Cholesky - CPU only

Ok so lets do the minor cleanups and then merge this one.
BTW it is not useful without a triangular solver, maybe this patch should already include it?

@karlnapf For the triangular solver, I'm thinking:

Add a separate interface such as SGVector<T> triangular_solver(SGMatrix<T> A, SGVector<T> b) and call Eigen3.llt().solve() inside triangular_solver(). This means triangular_solver() and choledsky_llt() will be two independent methods, and user can still call cholesky_llt() for whatever purposes (is this necessary?)

I assume we still need to implement QR decomposition etc. some time later, so maybe we can implement a generic interface, for eg. `SGVector linear_solver(SGMatrix A, SGVector b, enum decomposition_type ).

There is upsides and downsides with that.
Maybe we can use "cholesky_solve", like scipy? One methods per factorisation .... I dont like passing enums on the decomposition types around too much
https://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.linalg.cho_solve.html
https://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.linalg.cho_factor.html

Let me know when this is ready to be merged

Ok let me know once this is done

@karlnapf squashed and ready

Let me know how things go and whether you need help

@karlnapf I bypassed the class name issue but the (TriangularView.transpose()).solve is not working on Travis. It is also a version issue and I am trying to make it backward compatible. Or do you think we should just keep it like this but for the users to upgrade Eigen by guarding?

UPDATE: I downloaded Eigen 3.1.2 on my machine (the minimum required by shogun's cmake) and the all tests can pass. So I am not sure what causes the inf return value on Travis

I'll check this these days...
Is everything else in here clean? Then I'll clone locally and try to come up with a fix...
Ping me if nothing happens within a week or two

@OXPHOS
Nice work!
Please let me know once you implement these solvers using GPU acceleration. I will do test them in GP.

Merge conflicts

@karlnapf updated

There is still this inf error on travis. What was it again with that?

My machine returns correct results with Eigen 3.1.2 (The minimum required) and the newest version of Eigen so I am actually not sure what happens on travis. (Though I am now thinking maybe there's some problem with the specific version of Eigen Travis is using?)

Yes it will be a specific version problem.
Would you mind getting the same version that is running on travis (ubuntu 14.04, installed from the repository, see config/Dockerfile), and compile with that locally to find out whether you can reproduce the error locally?
Next step: how to fix (I bet it has to do with the upper/lower interpretation changed or something)
Then, if that is possible, we need to write a guard that fixes the problem for the particular eigen3 version

Update:
Ubuntu14.04 uses Eigen3 3.2.0-8 according to this page. I downloaded Eigen3 3.2.0 and added 3.2.0-8 patch manually - not sure whether I missed something but the test can pass on my machine.
I don't understand why Ubuntu seems using "unstable" versions all the time but I did test the "stable" versions that can downloaded from here with a script here. All Eigen3 3.2.x, Eigen3 3.1.3 and Eigen3 3.1.4 give correct outputs on cholesky_solver test.
However, Eigen3 3.3.x lead to multiple mixed-type errors and I am looking into them.
@karlnapf

One way to go ahead here would be to disable the tests, and put a warning about the eigen3 version in cmake, see https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/CMakeLists.txt#L222

Update: I reproduced the error in Docker and the trouble came from this line. I'll see what I can do about it.

Note: Compiling error associated with Eigen3.3.x was documented in #3644

@karlnapf The error is produced on Travis due to the misbehavior of  Eigen::TriangularView.solve(). Not sure how this is happening but I temporarily disabled Cholesky_solver() test. Otherwise it is ready to merge.


Allow users to change username

From danielwertheim on Twitter

The implications of this are interesting.  What would happen to packages that have this username as the owner?


Not losing HP after threshold

Same guy from the Iron golem. I have registered 100+ infection, and I'm not losing HP.  (even with the defaults values)

Unable to reproduce. Suspect that other config values are in play that could mess it up. Though it isn't a constant stream of damage (random chance every tick)

Please send a copy of the server's config (or your config if singleplayer). Besides potential mod conflicts, it's the only idea I have about this issue.

I made sure to be away from the campfire, so as to not trigger the campfire effect

Villager doesn't react with the infected

For the eggs one, I've set it to 100, so I could jump from 0 to 100 instantly.

Suggestion - A Config option which edits how common the dmg tick happens when over the dmg threshold.
Update on my attempts: I've reduced the mod list to
(1) autoconfig1u-3.3.1.jar
(2) cardinal-components-api-4.1.2.jar
(3) cloth-config-6.2.57-fabric.jar
(4) immortuoscalyx-1.2.2-1.18.jar
(5) jei-1.18.1-<IP_ADDRESS>.jar
(6) recipecache-0.2.1-1.17.1.jar
(7) starlight-1.0.1+fabric.0583973.jar

And I haven't seen any dmg tick so far(about 2 mins into the game already

Very strange. I'll need to make a debug config to add optional log printouts. If it still isn't working with that, but does on my device, then something has gone terribly wrong. I do apologize for the inconvenience. I'll try to come up with such a build before all too long

Maybe a Fluke data corruption? I haven't attempted to reinstall from scratch yet though

But I can't afford to reinstall from scratch because.. Progress and mods configs ¯_(ツ)_/¯

All good. Possible it was a fluke, but unlikely. In any case I'll still be making a test build just to see if I can figure it out. If not, I suppose I can close the ticket for now and wait until it pops up again. I am still however planning on making a debug config that gives more info for these sorts of. Absolutely bizarre occurrences.

Definitely

Occasional damage is about what I was aiming for. Something I was curious about, did these issues occur before you installed the update for the previous bug? If not then it really does just sound like an absolute fluke.
If this is the case, I recommend backing up your world, deleting that copy of immortuos, moving the new one in, and maybe moving the config out for good measure. Then update a freshly generated config to have the values you originally wanted. If this truly was a fluke, this should fix it without any issues to your world. Of course this is not a guarantee, and you should always have a backup before you try anything like this.

On the first server run with the mod, I was with a friend all running around the world trying to get the mats for the anti-parasitic serum because we thought we would insta die once we reached the 100 threshold. Well, it was kinda anticlimatic with nothing happening but half black screen. Now that I mention this, it would be interesting to allow "insta death" but pure suggestion anyways.
So we could say it happened since the install

If you want instant death, you can config it to happen. You only need to set INFECTIONDAMAGE to a higher value. 20 should instantly kill the average player, but something much higher would ensure death.

Oh, Is there a way to edit the msg prompts? I was thinking about - like just when they get blind or reach the dmg threshold send an extra message saying "The Parasite is rampaging over and trying to take over your body - Store your stuff so you can retrieve it later!" so to give them a small clear-headedness moement before they lose any material progress

At this time no, may be possible through resource packs later when I convert the messages to translatable components instead though. Would just need to overtake an existing message.

I see. Oh, well. About the dmg bug. I've tested things. AND.... For some strange reason I only received dmg when I ran the server with
// Changes when players will start being damaged by the parasite
"EFFECTDAMAGE": 5,
Not sure if it was because of reinstall or because of that though, but most likely because of that, since re-running the server with EffectDamage:5 stops me from receiving dmg

Gonna test it with 10 though

That's real odd. That setting controls when the user starts getting harmed

Alright, maybe I indeed forgot about the infected player( I didn't disable blind). As for Single player I do get dmg tick though. So Either server Hosting issues, or due to a server side, gonna run a couple tests first before anything

Results: Nothing useful - I give up.
More details:

Hosting Server: Aternos
Fabric 1.18.1 (0.13.1)

_Steps: While Runing(Delete Mod and Config Folder) > Stop Server > Start Server

Stop Server > Install Immortuos and related > Start server to create config files
Stop Server > Edit Config > Start Server > Log into the Server

Test 2: Same as above, but I also loaded my player in between every server start._
I might come back if there's debug configs so I open another ticket if there's any info you would like for me to send

I think for now I will probably close out the ticket. I don't have the time to commit to a debug build at the moment, but over the weekend I should have a bit more (Maybe tomorrow). It sounds like maybe something is just being weird with damage, whether it's another mod or that particular install of immortuos, as I can't get the same issues to occur. When the debug update does come out, if the issue persists after updating, if you would like to start another issue (or reopen this one) with a log of the damage trying to run for a while, that'd be pretty neat though. Thank you for your time and for reporting!


corelib/date_time7_test.dart confused about transition from winter time to summer time

corelib/date_time7_test seems to fail during the period of time where the US uses summer time and EMEA has not yet switched to summer time (as shown, for example, here).

Duplicate of https://github.com/dart-lang/sdk/issues/55159


Postgresql named window support: FROM ... WINDOW name support

See: https://www.postgresql.org/docs/current/tutorial-window.html
SELECT sum(salary) OVER w, avg(salary) OVER w
  FROM empsalary
  WINDOW w AS (PARTITION BY depname ORDER BY salary DESC);

Currenty fails as it expects WINDOW after the OVER.

This is not (yet) supported. PRs are welcome or do you want to support the implementation of this feature in other ways?

I'm not sure how to implement it yet, I took a quick look at WindowElement() . I'll think about it a bit :)

@wumpz what other ways of support were you thinking of?  I have a rather large set of real-world Postgresql scripts I can test against  (that is how I found the other issues as well)

@d2a-raudenaerde: In my understanding there are two ways to get features implemented -- either write the code and submit a PR or sponsor an implementation. Especially when you ask for features, which do not have any direct benefits for the developers, a bounty might attract the needed interest.
Its one thing to freely share code, which I wrote mainly for my own needs. Its a different thing to work on someone else's requirements.

@manticore-projects my time costs money as well, so I totally understand :) How would funding building features work? I could not find much info except a 'sponsor' tag, which I assume goes to Tobias?

You are welcome. Tobias started this projects and did all the heavy lifting.
If you like to sponsor him some coffees or beers, we definitely will feel encouraged to work harder on Postgres related issues. (We both like PostgreSQL a lot, but do not use it for our daily business. Although MS SQL would cost you dearly -- just kidding.)
If you want to have something more binding with clear deliverables, please state your offer and expectations here.
When there is a d'accord, you still send to Tobias and we would sort it internally.
I will also pick up the idea again, to place Bounties more prominently on the page.
Thanks for considering!

I think I'm going to buy both of you beers / coffee :) I'm not a business myself, but I will ask my employer (when he's back from holidays) if we can do more official support stuff.

A sponsorship for a more complete Postgres Grammar would be most welcome and deserved to be shown prominently.
Thanks for your moral support too.

I am on it.