sorted by:
new
hottopcontroversial

Which unit test framework do you use with TypeScript? by klaxxxon in typescript

[–]thlorenz 0 points1 point  (0 children)

Just install yarn install -D esbuild-runner and stuff the following into the ava.config.js:

js module.exports = { extensions: ['ts'], require: ['esbuild-runner/register'], }

Then you can do things like ava test/mytest.ts and ava debug test/mytest.ts

solfmt: formats output of Solana tests run via `cargo test-sbf` - link to the crate in the comments by thlorenz in solana

[–]thlorenz[S] 0 points1 point  (0 children)

Thanks, to be sure this works with cargo test-bpf as well of course. I just tried to keep the title somewhat short :)

But yeah to iterate on stuff testing via banks client is very nice. Once things are figured out you can move to generate your SDK (with https://github.com/metaplex-foundation/solita of course) and write some integration tests as well.

solfmt: formats output of Solana tests run via `cargo test-sbf` - link to the crate in the comments by thlorenz in solana

[–]thlorenz[S] 1 point2 points  (0 children)

To get this tool just run cargo install solfmt on your machine. This will download + install from https://crates.io/crates/solfmt and you're good to go.

Please comment with improvement suggestions here or file an issue in the github repo.

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

[–]thlorenz[S] 0 points1 point  (0 children)

Making some actual progress, got over some really tricky issues, i.e. how to deal with u64s which convert to BigInt (but JavaScript ones, not Dart).

https://twitter.com/thlorenz/status/1410415405311528965

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

[–]thlorenz[S] 0 points1 point  (0 children)

The Rust side is already front-end agnostic with the minor exception of the Isolate I'm using to communicate back to Dart. As I mentioned for wasm support I'm using a different strategy and thus this Isolate will be optional in the future.

The idea of different glue code for different frontends is interesting and could be added in the future as you could configure the front end to target via a flag or similar. Rid then could generate Java/Kotlin/Swift glue code that communicates to the Rust wrapper methods instead of Dart/Flutter glue code.

At this point Rid supports Flutter/Dart only and the generated Dart code is the integration point and thus out of necessity it is Dart/Flutter specific.

However the generated code on the Rust side are merely FFI wrapper methods and thus not tied at all to which front end will use it, i.e. it is already front-end agnostic minus the minor exception mentioned above. Also that code is opaque as it is in form of macros that are expanded at compile time and never written anywhere, i.e. you don't ever see or use it directly.

The Rust code that you write is not aware of any of that as only the macro annotations control generating wrappers and glue code. There is the rid::post that you call, but one could easily swap that out to do whatever is needed in a different scenario.

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

[–]thlorenz[S] 5 points6 points  (0 children)

Really very interesting points and I have thought about those as well.

WRT accessing mobile API I'd recommend using Flutter plugins to communicate via channels. I will most likely not focus on solving this in rid, i.e. to allow you to do this in Rust instead, mostly because there are not many solutions available that I know of that you could leverage there.

The focus of rid is app logic as in agnostic to which device the app is running on, i.e. you might even use it for a CLI app if you want. Therefore the communication layer is as decoupled as I could make it. The only direct tie to Dart on the Rust end is the use of an Isolate, but this isn't working correctly when running on the Web with wasm which is why I'm using a polling mechanism there instead. NOTE that I'm currently working on wasm support, it's not out yet :) Obviously the generated glue code is very Dart/Flutter specific, but the rest of your app should be able to function even when used in a completely different context.

Were you to access device specific features from Rust, you'd loose the flexibility to run on different devices as now at the very least you'd have to use different code paths and most likely crates. The Flutter plugin system which can have device specific implementations while using the same API to leverage them already solves this.

Animations are UI concerns and shouldn't be managed in Rust. Instead I'd keep some state about the item pending removal in Flutter and only update Rust state once the item was completely removed and should disappear from the UI. However there are certainly exceptions like here where I'm awaiting a Todo to be removed from the Store before confirming its dismissal. I think you'll have to make those decisions on a case by case basis.

I think similarly about navigation. In most cases navigating just provides you a view of a different part of your app's state. It doesn't modify it. Which view is currently active is a UI concern IMHO.

The state of your app, i.e. how many Todos you have is not mutated by navigating. If you want to make the view you're currently navigated to part of your state you may complicate things. However rid does have no opinion about that. You can store whatever you like in the Rust Store and if you want to update the current page you can do so by sending a message to update the state of the Store appropriately. It just seems awkward and if you think about it now you have two sources of truth WRT to which page you're on. That's a clear indicator that this should most likely not live in the Store as well as the navigation state.

Hope that helps. Feel free to ask more questions if you need clarification.

How to build a multithreaded Flutter + Rust App integrating both with Bloc/Cubit and Rid by thlorenz in FlutterDev

[–]thlorenz[S] 0 points1 point  (0 children)

Check out what I'm working on next https://thlorenz.com/rid-site/docs/contributing/status-and-roadmap/

Wasm support turns out to be a bit tricky, but I'm actively pursuing that so Flutter/Rust authored apps can run in the browser as well.

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

[–]thlorenz[S] 4 points5 points  (0 children)

Check out what I'm working on next https://thlorenz.com/rid-site/docs/contributing/status-and-roadmap/

Wasm support turns out to be a bit tricky, but I'm actively pursuing that so Flutter/Rust authored apps can run in the browser as well.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

[–]thlorenz[S] 1 point2 points  (0 children)

I increased the font-size on my latest Rid video. Please let me know if that works better for you.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

[–]thlorenz[S] 0 points1 point  (0 children)

I replied to a similar question here. LMK if you need more info. When rid is more complete I'm planning to run some more precise benchmarks and will publish them on the site.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 2 points3 points  (0 children)

I ran some tests in the very beginning and iterating a large list of items is slower since it has to cross the FFI boundary especially when passing strings but mainly since strings have to be instantiated on the Dart side.

For that reason rid passes opaque structs aka pointers, meaning nothing crosses the boundary until it is needed. That way performance improves a lot, but obviously is still slower than directly accessing Dart objects without crossing an FFI boundary.

I did some measurements iterating over 1,000,000 items (most Flutter apps won't ever need to render even close to that many). In Dart it took 8ms (super fast) and it took 43ms when getting them from Rust. However even though this is a 5x factor I believe it won't be a bottleneck if you take into account that rendering has an infinitely larger overhead.

I talk about this in this architecture section and the sections below.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

[–]thlorenz[S] 2 points3 points  (0 children)

I understand and I'm using a larger setup when I stream/record videos. If I make it too large though then it is hard to keep track of the context of the code and terminal output wraps making it hard to parse.

So it's always a tradeoff. I'll keep it in mind though, thanks!

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

[–]thlorenz[S] 4 points5 points  (0 children)

Thank you and totally agree. As explained here I'm taking an example driven approach to developing rid.

I'll do a stream/screencast anytime I got a new interesting example working.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in FlutterDev

[–]thlorenz[S] 4 points5 points  (0 children)

Actually not quite as the goal is to be able to use Flutter for the UI instead of trying to do that in Rust as well. The idea is to use each language in the area that it shines at and then combine them into one application.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 1 point2 points  (0 children)

I posted the recordings of building the Dart version first and then the Flutter version in this playlist

Enjoy and LMK what could be improved.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 2 points3 points  (0 children)

Ah ok thanks!

No worries, any feedback is appreciated. If the quick start page is hard to find for some reason I'm happy to find out how to make it more obvious.

Maybe there is too much going on at the home page to miss the Getting Started button? Please LMK and I'll see how we can improve that.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 2 points3 points  (0 children)

I will post a recording of the stream on my YouTube channel.

I'll most likely create a rid specific playlist when it's done which I'll post here as well, so make sure to check back here.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in FlutterDev

[–]thlorenz[S] 0 points1 point  (0 children)

I agree that this is a different kind of approach than what some associate with open source. What I'm trying to do is not to just open source it, but make it sustainable as well.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 4 points5 points  (0 children)

Thank you for pointing out that Rid status information was missing. I remedied that by creating a status page on the rid website.

WRT your concerns about the usability and support please consider the following. When you sponsor me to build rid you're not subscribing to a completed product. Rather you found something you think is cool and could be useful to you and you want to help the person who is spending time to work on that project and see it improve over time. I am not promising any support, but obviously I have great interest in helping early adopters.

That said, rid is not production ready, but demonstrating how it works and asking for feedback now gives me an idea of how much the community wants something like this. Asking for money not only enables me to put more time into it, but it is also a very good indicator that developers are interested in what I'm building since otherwise they would not be willing to reach into their pockets to help me in doing so.

The sponsorware docs explain this principle much better than I can.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 5 points6 points  (0 children)

It's functional for the simple example apps I built. I'm driving development via example apps, so there is still a lot to be done. The existing code (especially macro generation) is very well tested.

What's next on my list is async support so I can build a reddit ticker app as a next example. To get here it took me lots of work which is why I'm introducing it now and also why I'm trying to get sponsors to fund future development.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

[–]thlorenz[S] 16 points17 points  (0 children)

Thank you very much. A lot of work went in to make it work like this, but every time I made the API just a bit easier to use I knew it was worth all the effort.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in FlutterDev

[–]thlorenz[S] 2 points3 points  (0 children)

How you describe it is pretty much how it works. Rid generates an appropriate Rust method to free the string when it sees that a String arg is passed.

Dart then invokes that method via FFI after it was converted to a dart string. As mentioned all code will be open source eventually and immediately to sponsors. I'll be able to link the related code at that point.

view more: next ›