Closed GutZuFusss closed 2 days ago
Wanted to try building with master, only to find out the commit was reverted: https://github.com/tursodatabase/libsql/commit/9499c3c40aa299b0ce5221b53f000f69462f8d8c
Please use another lib (anything, if you don't like sqlx, literally ANYTHING, I don't know enough to judge), even if the error from the screenshot is not caused by me using a version 2 minors down, this is not acceptable... Talking big about community maintaining, and then not even using the free feature of github tasks.
To do the bare minimum of checking if your stuff compiles... Unbelievable, this would be bad, if it was a runtime bug... But no... It does not build... for 5 month and now 3 minor versions...
That is annoying. To be completely honest though, I am not going to do anything about it. They seem to be aware of it and will likely fix this long before this project here ever gets even half complete. Even then, official windows build would be done by github actions that crosscompile to windows. If I understand the issue correctly, those builds should still work, since they are done on a linux host, which would understands cp commands in build scripts. That means this only effects development on windows, for which just using wsl seems to be an exponentially easier fix for the time being than switching databases again.
I know this is not the answer you wanted to hear, but my time is limited and I basically only use this to debug the sf-api with a slow effort to bring in new features when I am bored on a weekend. If you feel like the db needs to change again, feel free to revert to the fixed sqlx version you had and keep that fork alive on your github
I just said, I don't want sqlx xd
if you say its no good, its probably no good, but theres gotta be something else, man... are you on linux?
for now i will just use the version the dude submitted in his PR, does the current master of sf-server work for you?
are you on linux?
mac
does the current master of sf-server work for you
yes, just tested to make sure
does the current master of sf-server work for you
Just got the info, that S&F updates their client drastically today. If I had to guess it is not working anymore, but I have not checked..
does the current master of sf-server work for you
Just got the info, that S&F updates their client drastically today. If I had to guess it is not working anymore, but I have not checked..
I actually was aware and missed to... Uhm... Backup... The client.
does the current master of sf-server work for you
Just got the info, that S&F updates their client drastically today. If I had to guess it is not working anymore, but I have not checked..
Well, guess I'll just give it a try myself I would have done quite some things differently, especially regarding reusing data structures instead of copying the same blocks of add_xxx().add_yy() over and over. Also I will have the serializing be done with the chain builder pattern, which I think could work really well in Rust as it does in languages with focus on unmutable datastructures. Basically I think I will be going for many small serializers that then will be stacked like legos to bigger deserializers. Looking at the patterns that emerged in your variant, I strongly suspect that this is what Playa has done aswell, it just works out a little too well. For example I would have a deserializer for the portrait, that would then be part of the "bigger" serializers like for the character or HoF responses, without repeating any code (or even whole passages).
On a side note, this would have prevented the situation this project finds itelf now in for the most part, as there is more like a "single source of truth" which is always a lot easier to maintain. One of the most important lessons to learn in professional coding, being able to code anything you want is worth nothing many people can do it. I would consider this basic, as well as the common programming paradigms and clean code principles. The real art is to be able to anticipate future needs and - I can't stress this one enough - write code with that is maintainable with many people having the same understanding. A low coginitive complexity (https://docs.codeclimate.com/docs/cognitive-complexity) really goes a long way there. I always chose linters that have a metric for this, because yes, this is for the most part measurable objectively. I think that is the biggest weakness of the code here and in sf-lib, hope you don't take this the wrong way. This shows great intellectual comprehension, it's just that in larger projects that are not of an academic, but real-world nature (as in: will not be abandoned in any foreseeable future)( can be positive. A client of mine had a guy like this, he was a doctor and really unfathomably smart to me. He wrote this part of the software in the early days of the company with very little oversight, that did not at all have to be as insanely complex as it was... But rewriting it from scratch would have been so expensive, that he became aware that he was practically not fireable and used this leverage extensively in negotiations.
Of course I understand, that recreational coding is supposed to be fun, and I get that this means something else for different people. Maybe that's why I lost my sparkle for coding in my freetime a long time ago... Who knows.
For persistence/db stuff, I will be using https://diesel.rs/ which I have been told the cool kids are using by fellow cool kid @heinrich5991
cargo build output:
Appears to be an older issue, that is not getting particularly much attention: https://github.com/tursodatabase/libsql/issues/1657 Apperently after 5 month and 1 minor version this problem was deemed worthy of a fix: https://github.com/tursodatabase/libsql/pull/1791 Still unreleased though, probably for a while. Thanks Fireship, I guess: https://www.youtube.com/watch?v=PGpL5hYpY1o
Downgrading from 0.6.0 to 0.4.0 (!) allows me to compile, I then can't create an account anymore, not sure if thats related to the downgrade:
Can I somehow use prebuild binaries or smth? Very annoying, I'll reimplement logging for troubleshooting...