Update windows build on release page

[make-42]

The Windows build available for download on the release page is pretty old (11 months), it would be pretty great if someone could release a newer version for Windows.

[nikp123]

Or I'd rather prefer automated releases, since manual builds take up SO MUCH effort and testing.

I would just like to be rolling-release instead.

[make-42]

yeah!

[nikp123]

Also worked a bunch on making the visualizer more "packagable", just so you know.

[nikp123]

https://github.com/nikp123/xava/runs/3432863883

this took embarrassingly long to make

honestly switching to rust from now on lmao

[nikp123]

https://github.com/nikp123/xava/runs/3434128068

[nikp123]

https://github.com/nikp123/xava/tree/unstable

Unstable downloads are automated and in the README now

[make-42]

Error from latest build...

[nikp123]

can you show the file, I probably should've attached the filename in the logs

[make-42]

what file?

[nikp123]

depending on the shader that's loaded either the pre or post fragment could be at fault

[make-42]

where are the logs?

[nikp123]

Anyway, I've pushed a new commit with more verbose logging on. Wait about 5-ish minutes for the CI system to make an installer for it.

[nikp123]

once the circle's green you're free to download the new release basically, it's that easy now

update: checkmark

[make-42]

offending file path: xava/gl/shaders/pre/default/fragment.glsl

[make-42]

i would imagine an issue with loading the file but it is there and accessable...

[make-42]

well now i know...

[make-42]

[make-42]

why are they there tho?

[make-42]

deleting them lets XAVA start normally.

[make-42]

these are not present within the copy in the exec dir

[nikp123]

Check if its like that in the install dir. If it is, then it's CMake's fault. If it's not it's a C memory management issue on my side.

Although I'd recommend just deleting the shader folder (just once) because there were like 10 builds previously that had that issue.

[make-42]

nope, deleting the file makes it not work again...

[nikp123]

Have you checked the file at the installation dir. If it's fine then it's a memory management issue hiding somewhere in the code.

[nikp123]

It's at C:\Program Files\xava\gl\shaders\pre\default\fragment.glsl

[make-42]

it's fine

these are not present within the copy in the exec dir

[make-42]

Time to make the code rusty!

[nikp123]

Honestly that sounds like a fine task for a crabby friend.

[nikp123]

oop

[nikp123]

Hasn't been rusted yet, but I fixed the issue. It was the same fucking problem with "binary-incompatibility" and windows behaving by god-awful coding standards.

tl;dr: Guys at CERT (some C standards committee) decided that OS-es should be free to decide how file operations should behave when you do not EXPLICITLY specify the "b" flag, making it ESSENTIALLY undefined behavior. You can thank them later for creating billions of bugs. As such, Windows made its own FILE operations behave how it wants, as opposed to Linux/POSIX who were like: "No, that's stupid!". That means that your code will work on LInux/macOS but not on Windows, due to something as stupid as this.

[nikp123]

https://github.com/nikp123/xava/releases/tag/0.7.0.0

Version automation now works :D

[make-42]

Standards are always a pain in the ass to work with especially when they vary system to sytem.

Hasn't been rusted yet, but I fixed the issue. It was the same fucking problem with "binary-incompatibility" and windows behaving by god-awful coding standards.

tl;dr: Guys at CERT (some C standards committee) decided that OS-es should be free to decide how file operations should behave when you do not EXPLICITLY specify the "b" flag, making it ESSENTIALLY undefined behavior. You can thank them later for creating billions of bugs. As such, Windows made its own FILE operations behave how it wants, as opposed to Linux/POSIX who were like: "No, that's stupid!". That means that your code will work on LInux/macOS but not on Windows, due to something as stupid as this.

Anyways the issue is fixed on my side.

[make-42]

And version automation sounds good!

[nikp123]

Since we're here, I was thinking what's the best way to redo the documentation?

The config file is tolerable, but the README is god awful.

I wanna make this easy-er-ish to use. Not targeting your average person, but essentially not forcing the user through a learning curve.

[make-42]

Umm, it's fine in my opinion but this is your project.

[nikp123]

Who knows, maybe I'm just pessimistic.

[nikp123]

Regardless issue solved :P