It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like:Chrome,Firefox,Internet Explorer orOpera

×
avatar
shmerl: Are GOG developers monitoring it?
Are you implying they actually have developers? Heh...
avatar
mattymuc: Welcome back Judas! I hope you had a relaxing holiday!
avatar
JudasIscariot: It was so relaxed that it could have been considered debauchery :P
You're never too much relaxed.
Ok, may be when your brain is flowing on the floor, here, it's too much.

Welcome back ! Hope you had good vacations :) (and it seems to be the case)
Post edited 2 days ago by Splatsch
avatar
JudasIscariot: I've only seen that when I had issues with my internet speed but that's just me so YMMV :)
avatar
rtcvb32: If it cleared up on it's own that's one thing (lag of downloading CSS and other resources). It's not for me.

avatar
mrkgnao: I think this should go in the "what did just break" thread.
avatar
rtcvb32: You may be right, but i don't have that thread faved so finding it might be a pain...
Try clearing your cache and reloading. Some browser setups (especially Chrome-based ones) will run into a network hiccup and then cache the "couldn't retrieve this CSS file" response as if it were a successful response.

(And I DO mean "clear your cache". The hotkey for "reload bypassing cache" is glitchy under Chrome. When I'm testing changes to my creations using Chrome, I often have to "reload bypassing cache" multiple times in a row to get it to acknowledge that there's a newer version on the server and, sometimes, it'll even flip back to the stale cache entry after having successfully displayed the newer version.)
Post edited Yesterday by ssokolow
avatar
ssokolow: Try clearing your cache and reloading. Some browser setups (especially Chrome-based ones) will run into a network hiccup and then cache the "couldn't retrieve this CSS file" response as if it were a successful response.
I just cleaned the cache last week when i had login issues during the sale... ugg...

edit: K cleared it and made no difference...
Post edited Yesterday by rtcvb32
avatar
shmerl: Are GOG developers monitoring it?
avatar
Wurzelkraft: Are you implying they actually have developers? Heh...
Of course they have.
avatar
Wurzelkraft: Are you implying they actually have developers? Heh...
avatar
shmerl: Of course they have.
Of course they have, but it seems management has them focus entirely on adding new features, rather than debugging existing ones.
avatar
shmerl: Of course they have.
avatar
mrkgnao: Of course they have, but it seems management has them focus entirely on adding new features, rather than debugging existing ones.
I suspect they don't have enough people but have very ambitious goals (like Galaxy).
Post edited 13 hours ago by shmerl
avatar
mrkgnao: Of course they have, but it seems management has them focus entirely on adding new features, rather than debugging existing ones.
avatar
shmerl: I suspect they don't have enough people but have very ambitious goals (like Galaxy).
Indeed. And I would say that from their POV they are right. I don't suspect many people have left because of the bugs, but I seem to see hordes flocking in at the mere mention of a client (and a witcher).
avatar
shmerl: I suspect they don't have enough people but have very ambitious goals (like Galaxy).
avatar
mrkgnao: Indeed. And I would say that from their POV they are right. I don't suspect many people have left because of the bugs, but I seem to see hordes flocking in at the mere mention of a client (and a witcher).
*nod* That's why companies ahead of the curve trumpet "Never test by hand." It forces you to research suitably low-friction test systems (a one-time cost) and then you spend about the same amount of time but every test you ever do can be trivially re-run to catch regressions and, as a side-effect, you spend less time worrying about the correctness of code you've written and more time actually coding.

(It's also why companies like Google come up with solutions that let them code in a language with stricter compile-time guarantees like Java and then transpile to JavaScript. Programmer time is expensive and humans make bad auditors. CPU time is cheap and computers are pedantic by nature.)
Post edited 12 hours ago by ssokolow
avatar
ssokolow: (It's also why companies like Google come up with solutions that let them code in a language with stricter compile-time guarantees like Java and then transpile to JavaScript. Programmer time is expensive and humans make bad auditors. CPU time is cheap and computers are pedantic by nature.)
With WebAssembly I expect it will be trivial to write in Rust and compile that into Web applications:
https://github.com/WebAssembly/design/blob/master/README.md
https://github.com/WebAssembly/design/blob/master/FAQ.md
https://www.w3.org/community/webassembly/
Post edited 11 hours ago by shmerl
avatar
ssokolow: (It's also why companies like Google come up with solutions that let them code in a language with stricter compile-time guarantees like Java and then transpile to JavaScript. Programmer time is expensive and humans make bad auditors. CPU time is cheap and computers are pedantic by nature.)
avatar
shmerl: With WebAssembly I expect it will be trivial to write in Rust and compile that into Web applications:
https://github.com/WebAssembly/design/blob/master/README.md
https://www.w3.org/community/webassembly/
That's what I'm hoping for. Looking back on when I've burned out on personal projects, half of it has been trying to use unit test suites and manually-coded checks to attain Rust-level guarantees in another language.

As soon as I finish catching up the mess of backlogged stuff I currently have to do, I want to sit down and practice the hell out of Rust. (Initially, by doing a fairly straight port of my gif.py frame counter to satisfy my curiosity as to whether the Python runtime imparts statistically significant overhead on optimized, I/O-bound code.)
avatar
ssokolow: As soon as I finish catching up the mess of backlogged stuff I currently have to do, I want to sit down and practice the hell out of Rust. (Initially, by doing a fairly straight port of my gif.py frame counter to satisfy my curiosity as to whether the Python runtime imparts statistically significant overhead on optimized, I/O-bound code.)
I'm going through the Rust book now gradually, and so far the language looks pretty neat. An interesting mixture of functional and object oriented approaches with a very strong bend on memory safety. I want to test it also on something practical.
avatar
ssokolow: As soon as I finish catching up the mess of backlogged stuff I currently have to do, I want to sit down and practice the hell out of Rust. (Initially, by doing a fairly straight port of my gif.py frame counter to satisfy my curiosity as to whether the Python runtime imparts statistically significant overhead on optimized, I/O-bound code.)
avatar
shmerl: I'm going through the Rust book now gradually, and so far the language looks pretty neat. An interesting mixture of functional and object oriented approaches with a very strong bend on memory safety. I want to test it also on something practical.
Yeah. Before things really became a crusher, I read through the Rust book once and I've already started reimplementing gif.py's CLI using the clap argument parser. I just need time to get back to the effort and write the internals which are more heavily affected by the differences between Rust and Python.

So far, everything I've seen seems to indicate that the only bits I know I dislike are bits that are considered to be issues but were explicitly "postponed until after 1.0" and then postponed again because compilation speed and better Windows support were both low-hanging fruit (due to also being "postponed until after 1.0") and much more immediate concerns. (Stuff like the borrow checker being stricter than necessary)
Post edited 11 hours ago by ssokolow