System level dependencies are not handled by the cargo file and are not indexed or listed anywhere.

It's really annoying to do this for releases

{"reason":"compiler-message","package_id":"rust-g 0.5.0 (path+file:///D:/a/rust-g/rust-g)","manifest_path":"D:\a\rust-g\rust-g\Cargo.toml","target":{"kind":["cdylib"],"crate_types":["cdylib"],"name":"rust-g","src_path":"D:\a\rust-g\rust-g\src\lib.rs","edition":"2018","doc":true,"doctest":false,"test":true},"message":{"rendered":"error: statics have by default a 'static lifetime\n --> src\redis_pubsub.rs:7:24\n |\n7 | static ERROR_CHANNEL: &'static str = "RUSTG_REDIS_ERROR_CHANNEL";\n | -^^^^^^^---- help: consider removing 'static: &str\n |\n = note: -D clippy::redundant-static-lifetimes implied by -D warnings\n = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_static_lifetimes\n\n","children":[{"children":[],"code":null,"level":"note","message":"`-D clippy::redundant-static-lifetimesimplied by-D warnings","rendered":null,"spans":[]},{"children":[],"code":null,"level":"help","message":"for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_static_lifetimes","rendered":null,"spans":[]},{"children":[],"code":null,"level":"help","message":"consider removing 'static","rendered":null,"spans":[{"byte_end":181,"byte_start":169,"column_end":35,"column_start":23,"expansion":null,"file_name":"src\\redis_pubsub.rs","is_primary":true,"label":null,"line_end":7,"line_start":7,"suggested_replacement":"&str","suggestion_applicability":"MachineApplicable","text":[{"highlight_end":35,"highlight_start":23,"text":"static ERROR_CHANNEL: &'static str = \"RUSTG_REDIS_ERROR_CHANNEL\";"}]}]}],"code":{"code":"clippy::redundant_static_lifetimes","explanation":null},"level":"error","message":"statics have by default a 'static` lifetime","spans":[{"byte_end":177,"byte_start":170,"column_end":31,"column_start":24,"expansion":null,"file_name":"src\redis_pubsub.rs","is_primary":true,"label":null,"line_end":7,"line_start":7,"suggested_replacement":null,"suggestion_applicability":null,"text":[{"highlight_end":31,"highlight_start":24,"text":"static ERROR_CHANNEL: &'static str = "RUSTG_REDIS_ERROR_CHANNEL";"}]}]}}

Pub/sub is great for events if you have something listening, but not so great if you care about a historical record of the data if no one happens to be subscribed at the time. For such a use case, lists are better suited combined with a worker-style implementation via BRPOP.

Would be neat to have the ability to push to, and pop off, lists.

(LPUSH and LRANGE)

https://github.com/tgstation/tgstation/blob/master/dependencies.sh

Not an intentional change, will investigate later. This means we would have to upgrade two Major debian versions so not super ideal...

Title, this has bothered contributors besides myself, who have to tell git to ignore our changes to make it the msvc target instead.

Essentially, the png crate was now checking for valid palettes in indexed image files or similar (was being copied before maybe? dunno how it would though) so we need to copy over the information from the original image

Raised in: tgstation/tgstation#68690

Given the wider use of this library by the ss13 community I thought it would be a nice thing to move the repo to spacestation13 where it can better represent it's shared nature.

It's much easier these days with a button to migrate and github maintaing redirections so it's much less likely to break CI across the world.

@tgstation/rust-g-dev-team thoughts?

As far as I can tell, #98 broke rustg_read_toml_file. We are using it in a tgstation branch, and when I happened to update rust_g, everything that depended on toml files broke.

the toml_file_to_json function in the library passes a json string containing "success" and "content" to byond, and the byond wrapper proc returns the value of "content" if it succeeds. From what I can tell, the value of content is escaped so that it is not actually parsed by json_decode() during this process, and returned as a json-formatted string (thankfully, with escape characters removed) instead of an associative array.

My current workaround is to json_decode the content again before you return it, and that appears to be working.

Test code (in an otherwise empty test environment, with rust_g.dm and a data.toml file to test):

world.New()
        world.log << "Starting"
        var/list/result = rustg_read_toml_file("data.toml")
        world.log << "Read done"
        if(istext(result))
                world.log << "It's just text"
                world.log << result
                var/list/result2 = json_decode(result)
                if(istext(result2))
                        world.log << "still just text"
                else
                        world.log << "converted?!?"

For me, this code returns the incredulous "converted?!?" text. The workaround is also functioning on a live server, providing the correct associative list for the data loaded from file.

We faced issues with a few people where they couldn't use even old copies of rust-g because of obscure "The specific procedure could not be found" errors. Eventually they had to install vcredist AND restart their computer before it was fixed.

We should statically link vcredist to stop errors like these.

You just need this in .cargo/config.toml:

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

(Also reminder to fix #86)

This override in the DM API file is incorrect:

#define text2file(text, fname) rustg_file_write(text, fname)

rustg_file_write overwrites, while text2file appends.

Low priority because /tg/ does not currently use the file module or the RUSTG_OVERRIDE_BUILTINS feature.

Byond's text2file would automatically create the folders needed to make the file. rust_g doesn't seem to want to do this and does not create the folders required to make a successful write operation, meaning that the file is never created in the first place.

Need to connect a panic hook or use dont_panic (or whatever its called) or something.

e.g. https://github.com/tgstation/tgstation-server/releases/download/dmapi-v5.2.7/DMAPI.zip (Not in practice but good example)

Signature: rustg_download_and_unzip_async(url, unzip_directory)

Should use the current jobs system.
Should handle and report all errors on return.
On success, should unzip the contents of the .zip pointed to by url into uzip_directory (which may be a relative path), creating it if necessary and overwriting any conflicting contents.

Bounty revoked, I need to make myself learn rust.

Rustg methods that replace byond methods should behave identically or only expand on the behavior of the byond method. A github code search of "rustg_file_exists" shows that every single user of this method thinks it returns a truthy or falsey value. However, this is not the case.

This now occurs when using 3.2.0, whereas in 3.0.0 it didn't

Reportedly occurs during high load procs such as round setup before start.

I intended it to always output with atleast precision 6 and didnt realize that f64 to string would output it as a whole number

Code:

/client/verb/noise_test()
    var/test = rustg_noise_get_at_coordinates(rand(1,1000),128,128)
    to_chat("The result is: [test]. Is it null? [isnull(test)]")
    var/test2 = md5("cock and ball torture")
    to_chat("The md5 is: [test2].")

Proof that I installed it right:

The result is: . Is it null? 0
The md5 is: 35f953af0a9f12c40b2da38f9b9df658.

Cargo install string used:

cargo build --release --features log,dmi,git,http,sql,noise,url,file,hash

Its a tall order, and absolutely fuelled by lunacy, but it may be something worthwhile?

Rust added a new clippy lint or something and it fails now:

 error: use of a fallible conversion when an infallible one could be used
   --> src\hash.rs:105:48
    |
105 |         let result = totp_generate(hex_seed, i.try_into().unwrap(), time_override)?;
    |                                                ^^^^^^^^^^^^^^^^^^^ help: use: `into()`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_fallible_conversions
    = note: `-D clippy::unnecessary-fallible-conversions` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(clippy::unnecessary_fallible_conversions)]`

error: could not compile `rust-g` (lib) due to previous error

Just switching to into() doesn't work as stated, since there is not a From conversion.

Param: Allow for non-direct-children in the list
Param: only files or only folders, default both

Also this bug: http://www.byond.com/forum/post/2639780

I am trying to update our (Aurorastation) rust_g version from 2.1.0 (+ some customized additions) to 3.10 (keeping the customized additions we have)

It seems on windows, the compile for the windows platform fails with:

error: initializer for `thread_local` value can be made `const`
  --> src\pathfinder.rs:11:48
   |
11 | static NODES: RefCell<Vec<Option<Rc<Node>>>> = RefCell::new(Vec::new());
   |                                                ^^^^^^^^^^^^^^^^^^^^^^^^ help: replace with: `const { RefCell::new(Vec::new()) }`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#thread_local_initializer_can_be_made_const
   = note: `-D clippy::thread-local-initializer-can-be-made-const` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::thread_local_initializer_can_be_made_const)]`
error: initializer for `thread_local` value can be made `const`
  --> src\redis_pubsub.rs:10:76
   |
10 |     static REQUEST_SENDER: RefCell<Option<flume::Sender<PubSubRequest>>> = RefCell::new(None);
   |                                                                            ^^^^^^^^^^^^^^^^^^ help: replace with: `const { RefCell::new(None) }`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#thread_local_initializer_can_be_made_const
error: initializer for `thread_local` value can be made `const`
  --> src\redis_pubsub.rs:11:82
   |
11 |     static RESPONSE_RECEIVER: RefCell<Option<flume::Receiver<PubSubResponse>>> = RefCell::new(None);
   |                                                                                  ^^^^^^^^^^^^^^^^^^ help: replace with: `const { RefCell::new(None) }`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#thread_local_initializer_can_be_made_const
error: initializer for `thread_local` value can be made `const`
 --> src\redis_reliablequeue.rs:7:52
  |
7 |     static REDIS_CLIENT: RefCell<Option<Client>> = RefCell::new(None);
  |                                                    ^^^^^^^^^^^^^^^^^^ help: replace with: `const { RefCell::new(None) }`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#thread_local_initializer_can_be_made_const
error: file opened with `create`, but `truncate` behavior not defined
  --> src\unzip.rs:50:14
   |
50 |             .create(true)
   |              ^^^^^^^^^^^^- help: add: `.truncate(true)`
   |
   = help: if you intend to overwrite an existing file entirely, call `.truncate(true)`
   = help: if you instead know that you may want to keep some parts of the old file, call `.truncate(false)`
   = help: alternatively, use `.append(true)` to append to the file instead of overwriting it
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#suspicious_open_options
   = note: `-D clippy::suspicious-open-options` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::suspicious_open_options)]`

I have also ported over the change made in #165 but without luck; I do not know much if anything about rust, but seeing the same error also happening in #160 it seems Clippy doesn't like some core rust_g code, hence opening this bug report

If I am wrong on the above assumption, please, do feel free to close this and let me know that I did something wrong on my side

After #119, the release build of librust_g.so is 70 MB as opposed to the previous 10 MB.

This is extremely unideal. There are two ways I see to solve this.

One is that we make release w/ debug info a separate target, then ship both librust_g.so and librust_g_debug_info.so.

Another is that there might be a way to split it into its own file much like the .pdb. There's a few StackOverflow posts about this, something about objcopy? Not sure how doable it is but that would be ideal if it's feasible

If you specify an output filepath to a folder that doesn't exist for a http request, you'll be hit with this error.
I'm unsure if this is a bug or not, but it's somewhat problematic for trying to store temporary files in a subfolder within the tmp folder on the tgstation repo.

dmi_strip_metadata leads to removing alpha channel from the icon
Here is the code I used:

/world
	fps = 25
	icon_size = 32
	view = 6

/mob/Login()
 	var/icon/test = icon('twitcher.dmi', "preview")
	fcopy(test, "temp.png")
	client << browse_rsc(icon("temp.png"), "first.png")
	call("rust_g", "dmi_strip_metadata")("temp.png")
	сlient << browse_rsc(icon("temp.png"), "second.png")

twitcher.dmi: https://cdn.discordapp.com/attachments/693217263934898190/1111983453760651324/twitcher.dmi

Code result:
first.png:

second.png:

I know it doesn't mean much in a context like this, but rust-g has been battle tested in many major servers and likely will not receive many backwards incompatible changes for a bit. Would be nice to move to 1.0.0 to better communicate what is happening in the updates.

fexists("path") on Linux return 0 for symlinked files.

why

Who knows but it'd be useful for some /tg/ prod shared config stuff.

Can we get a rustg_fexists(path) call please?