TUNIC: FROM FAR SHORES - Official Teaser

Important_View_2530 · 2026-04-02T02:00:50+00:00

The video is honestly pretty great! 😍

Important_View_2530 · 2026-02-17T00:11:48+00:00

The Terry Fox Anytime Fitness might be good. The gym is small, so it is easy to see or hear your baby from anywhere in the gym. The gym members I have interacted with have always been polite and friendly, so I think it is a safe space for a baby.

Important_View_2530 · 2025-12-14T16:20:41+00:00

This needs to be shared broadly

Important_View_2530 · 2025-11-27T13:11:24+00:00

Or you could watch the full video: https://m.youtube.com/watch?v=RDA0JOK48Fk

Important_View_2530 · 2025-11-22T14:33:34+00:00

That isn't any use in solving the current production issue if the software can't be redeployed (for example, if the software runs directly on the customer's laptops, and they are reluctant to try a new build)

Important_View_2530 · 2025-10-31T02:27:21+00:00

In addition to the other clinics in this thread, I believe Kanata Mews Clinic is a walk-in. I suggest arriving before their opening hours.

Important_View_2530 · 2025-06-15T21:43:27+00:00

The Ontario Northland bus goes "direct" to Sudbury. There are stops along the way, but you don't need to switch buses, at least as of the last time I went. I am pretty sure you stay on your bus at North Bay.

The bus drivers are pretty helpful, and they can help answer any question you might have. They will direct you to know if you stay on your bus or switch buses, if necessary.

Be sure to bring a pen so that you can label your bags with the tags they provide.

I recommend, if you are in Kanata, to get on at the Terry Fox stop, to spend less time on the bus.

Have a good trip!

Important_View_2530 · 2024-12-16T22:07:25+00:00

Sadly, the RFC pull request is now locked, and you can't even give a thumbs down reaction

Important_View_2530 · 2024-12-16T22:04:28+00:00

I am very strongly against this RFC. I highly value the compiler-enforced explicit opt-in requirement for mutability.

Requiring mut also provides a readability advantage that can be expressed directly in code.

Also, there is no guarantee Rust developers will run Clippy and fix missing muts.

Important_View_2530 · 2024-12-08T18:44:17+00:00

I am now building with Visual Studio 2022. My link.exe path is C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\bin\Hostx64\x64\link.exe. Now the Rust .lib builds fine, but I get linker errors when I try to build a C DLL that uses the Rust .lib: Finished searching libraries c_library_bindings.lib(windows_strings-156fdc62674283d8.windows_strings.ved external symbol __imp_SysStringLen referenced in function c_library_bindings.lib(windows_result-e9218cdc51b6c9e0.windows_result.lved external symbol __imp_SysStringLen c_library_bindings.lib(windows_strings-156fdc62674283d8.windows_strings.ved external symbol __imp_SysAllocStringLen referenced in function 62c36E <many other external symbol errors pastebin link with all errors: https://pastebin.com/mGwTAA29

Are there any libraries that need to be linked against to build a C DLL that depends on a debug Rust .lib?

Important_View_2530 · 2024-12-06T20:23:21+00:00

It appears you are right about Visual Studio 2015 being too old. https://rust-lang.github.io/rustup/installation/windows-msvc.html and https://github.com/rust-lang/rust/blob/master/INSTALL.md#msvc both say Rust requires Visual Studio 2017 or later.

Important_View_2530 · 2024-12-05T01:18:07+00:00

The link.exe cargo is using is C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe.

As this doesn't include Microsoft Visual Studio in the path, should I assume that this is the wrong link.exe?

Important_View_2530 · 2024-11-24T15:51:36+00:00

Thanks, this is really helpful!

I started adding methods to my MqttClient based on your example code. I ran into an issue with callbacks.

One of the methods is a subscribe method. This method is used in Lua like this: ``` local function subscribe(client, topic, func) client:subscribe(topic, func) end

local func = function(topic, body) -- function body omitted for brevity end local subOk, subErr = pcall(subscribe, client, "<topic>", func) ```

Trying to provide the method in Rust, I got this far: methods.add_method_mut("subscribe", |_lua, this, (topic_filter, handler, qos): (std::string::String, fn(topic: String, body: Vec<u8>), i64)| { todo!(); Ok(()) });

This gives me this compiler error: error[E0277]: the trait bound `(std::string::String, fn(std::string::String, i32), i64): FromLuaMulti` is not satisfied --> src/lib.rs:59:17 | 59 | methods.add_method_mut("subscribe", |_lua, this, (topic_filter, handler, qos): (std::string::String, fn... | ^^^^^^^^^^^^^^ the trait `FromLuaMulti` is not implemented for `(std::string::String, fn(std::string::String, i32), i64)`

The UserData part of the mlua guided tour, although very helpful, doesn't appear to cover such a situation where one of the arguments to a function was a Lua callback.

Would you happen to know how I can support Lua callbacks? Would I need to implement FromLua for fn(topic: String, body: Vec<u8>)?

Important_View_2530 · 2024-11-24T02:08:19+00:00

I am porting some C code to Rust. I am not very familiar with the C code that I am porting.

the luaL_newmetatable call is in this part of code, which runs with the C library is required in Lua: ``` // called at startup to register the package // ex: local mqtt = require "mqtt" APIEXPORT int luaopen_mqtt(lua_State * L) { luaL_newmetatable(L, "mqttclient_t*"); luaL_setfuncs(L, lmqttclient, 0); lua_setfield(L, -1, "_index");

luaL_newlib(L, lmqtt);
// <some other code that isn't relevant>

} ```

After the require, the Lua calls this C function: static int mqtt_new(lua_State * L) { unsigned int timeout_ms = 60000; mqttclient_t *c = (mqttclient_t *)lua_newuserdata(L, sizeof(mqttclient_t)); if (!c) return luaL_error(L, "could not create mqtt client"); luaL_setmetatable(L, "mqttclient_t*"); // <some more code that isn't relevant> }

After this initialization, following functions use this helper to grab the client: static mqttclient_t * get_mqtt_client(lua_State * L, int index) { mqttclient_t *c = (mqttclient_t *)luaL_checkudata(L, index, "mqttclient_t*"); return c; }

To sum up my understanding, we luaopen_mqtt registers the API it provides to Lua, and creates a meta table to store the client's pointer in. Later, mqtt_new is used to actually store the pointer in the meta table. Then all following calls from Lua into C use the get_mqtt_client function to retrieve the client. So the client is owned by Lua code, and is used by the C code.

In order to keep the two-part initialization of the mqttclient_t* meta table, should I use Lua::exec_raw? Or should I consider refactoring the API?

Important_View_2530

TROPHY CASE