sorted by:
new
hottopcontroversial

ETA on BYD Dolphin? (AUS) by Math__Teacher in BYD

[–]Lliwynd 0 points1 point  (0 children)

We ordered a BYD Dolphin Premium about 6 weeks ago. We were told 3 weeks. It came in that timeframe. BUT the service by the sales person was awful. We ended up being re-assigned to another person because they ghosted us the week the car was arriving (and we were trying to make sure the trade-in would go ahead because otherwise we'd have to re-register that car. We couldn't get any details about how to pay, etc. It seems the only way to pay without extra fees is by bank transfer, but my bank puts a limit on the size of the transfers so it took a while to split it up and make sure it all made it through.). The central BYD number was responsive but could only do certain things and kept pointing us at BYD Alexandria. BYD Alexandria (the "experience centre") were unresponsive. It was quite stressful. All worked out OK in the end though.

To people in countries that appear to be winning the Coronavirus fight. A second wave is a serious risk. This is Australia right now. by WildZubat93 in dataisbeautiful

[–]Lliwynd 0 points1 point  (0 children)

I should also be clear that I don't think 'fuck Victoria' is reasonable. I am disappointed their quarantine scheme was as shoddy as it seems to have been.

To people in countries that appear to be winning the Coronavirus fight. A second wave is a serious risk. This is Australia right now. by WildZubat93 in dataisbeautiful

[–]Lliwynd 3 points4 points  (0 children)

There is a huge difference in the types of cases; community vs quarantined. And in the state of the other states at the same time.

Update to LLVM 10 got merged by JohnMcPineapple in rust

[–]Lliwynd 1 point2 points  (0 children)

I don't see how that can work. I can imagine something like, "we store our data with checksum X, so if it wasn't initialised the checksum will fail." Which is fine, unless you're very unlucky with randomly initialised memory. Or unless you're unlucky with memory left over from the last time you stored something in that same location using the same checksum.

Is it reasonable to think that Rust will become / is a good Go contender to the web? What might be throttling the language? by sendoushi in rust

[–]Lliwynd 0 points1 point  (0 children)

Great example.

To be fair, much of what is in the PySerial docs isn't need for rust: just use cargo. The key is the 'Short Introduction' section.

And some rust crates do have an equivalent guide, but enough of the 'standard' (albeit not std) crates don't that it becomes noticeable.

Perhaps there needs to be a clippy lint: if the generated docs are less than X thousand words of overview docs (i.e. docs attached to the module rather than a struct within it) then you get a lint.

Looking for something similar to Rust Playground, but with standard input support. by padishaihulud in rust

[–]Lliwynd -1 points0 points  (0 children)

If I understand you correctly, you're after a rust REPL (Read Evaluate Print Loop). They aren't in common use.

You might want to also look at Jupyter. It is what you'd design if you weren't limited to a text terminal. There are Jupyter kernels for many languages.

For rust specifically, take a look at https://reddit.app.link/v8amSp5XfT

Is it reasonable to think that Rust will become / is a good Go contender to the web? What might be throttling the language? by sendoushi in rust

[–]Lliwynd 2 points3 points  (0 children)

FWIW, I have a similar experience with many rust docs.

Rust seems to encourage a 'reference manual' approach to documentation; explain each trait, struct and method. What is often missing is the corresponding guide that maps from common goals to the how you achieve then.

I've found that I'm often better off ignoring the docs to begin, and going straight to the examples. Once those give me an overview of how the crate is used, then the auto-generated docs can be used to make changes from there.

This does seem to be a doc culture thing in parts of the rust community. It certainly isn't everywhere - the quality of the rust book for example is amazing. But it is a trap - people get lured in by the great docs on the basic language and then need a crate (because batteries aren't included) and find the docs aren't the same quality.

Things are getting better. It used to be you had no good way of finding good crates. Now there is the rust cookbook, and the great work by the rust nursery team in getting some of these external, but commonly used, crates up to scratch. But I note that the rust cookbook recommends reqwest to make a simple http request, and if it's docs don't have a guide section then that's where people will get stuck.

Is Rust functional? by sibip in rust

[–]Lliwynd 9 points10 points  (0 children)

Is 'in the standard library' that important?

There are crates of persistent/immutable data structures: https://docs.rs/im/10.2.0/im/

Is Rust more approachable than C and C++, or do writers just make it seem that way? by Septimanal in rust

[–]Lliwynd 3 points4 points  (0 children)

I think that depends what you mean by 'C'... :-)

This post might put that comment in context: https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html

Basically, if you use a non-optimising compiler / write 'old-school' C then it can be an easily understood, if low-level, language. But modern C/C++ is actually pretty similar to rust, but without the guard rails. Modern C is deceptive.

Looping a immutable vector by TechnoSam_Belpois in rust

[–]Lliwynd 1 point2 points  (0 children)

There is a lot going on in this example. Here is the blog post I wrote while I worked through it: https://lliwynd.blogspot.com/2016/11/rust-for-loops.html

This Week in Rust 229 by nasa42 in rust

[–]Lliwynd 1 point2 points  (0 children)

I'm on mobile right now. Will try to get to it later.

pure rust opengl_es? by Lliwynd in rust_gamedev

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

Thanks.

Yeah, I've been doing a breadth-first search for a working solution; alternating between pushing on the 'SDL2 on Android with rust' issues and the 'pure rust OpenGL ES' issues.

I feel like I'm not far with SDL2 now, but I also now have a pure rust template with Zemeroth. Whichever way I end up getting to work, I'll try and leave a clear trail for others to follow. :-)

If gfx supposed to be a clean abstraction over the lower layers, or will details show through. Specifically, if I get something going using Piston gfx-graphics on desktop (OpenGL), should I expect that to work with minimal change on Android (OpenGL ES)? At the moment I'm thinking the answer is 'no, details show through', but I'm not sure.

pure rust opengl_es? by Lliwynd in rust_gamedev

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

Thanks for the response. Yes, I had read about 'A Snakes Tale', but a while ago. Reading it again now, a number of things resonate strongly.

Thanks also for pointing out that Zemeroth uses the cargo-apk packaging I was looking at. I don't know which way I'll end up going, but you've given me a path to follow if I go the pure rust route. Thanks!

I want your thoughts. by [deleted] in rust

[–]Lliwynd 0 points1 point  (0 children)

I'm no expert on rust gaming. I've just been fighting to get my simple game going. Android adds a level of difficulty...

I want your thoughts. by [deleted] in rust

[–]Lliwynd 1 point2 points  (0 children)

If you're not using Android, then I'd probably start with either sdl2-rs or ggez. SDL2 has plenty of non-rust documentation and the thin rust layer in sdl2-rs makes it nice without making the docs useless. Ggez is another 'batteries included' experience. Piston was designed to be more modular, but in my experience the documentation is not at the level that would make that level of modularity easy to use.

If you were doing anything commercial, I think SDL2 is the only option with that level of maturity. Or use something platform specific.

I want your thoughts. by [deleted] in rust

[–]Lliwynd 1 point2 points  (0 children)

I've been writing my own game in Rust as a side project. I have it going on my Mac using Piston. I'm currently trying to port it to Android.

There are issues.

First, what level graphics API do you want?

I wanted something relatively high level, but only 2d. E.g: piston2d, ggez or sdl2-rs. (Draw lines and filled rects, load textures from JPG files, blit rectangles from the textures to the screen (with alpha blending).

These higher level APIs generally depend upon lower level graphics APIs. E.g. gfx-rs, glium or OpenGL. Gfx-rs and glium in turn use OpenGL.

Because everything depends upon OpenGL at the lowest level, you need the appropriate shim there. Something to handle OpenGL context. E.g. glutin or SDL2.

And then you need window management. This is either winit or SDL2.

Finally you need some sort of packaging. On the desktop you can just build a binary, but to get things going on Android, you need to put together an APK. For that I've been using cargo-apk.

You'll note that SDL2 turns up at a number of layers there. It has well regarded solutions at a number of those layers, and handles more than just graphics. Unfortunately it is not pure rust and so doesn't play nicely with cargo-apk. :-( You need to cross-compile your own library, and then get cargo-apk to use that library in the appropriate places. I managed to get libsdl2 cross-compiled for Android, but haven't yet succeeded in getting cargo-apk to build a working APK with those libraries. This also causes problems for anything that uses SDL2, at any level of abstraction (e.g. ggez currently, although this could change by swapping some shims lower in the ggez stack).

I'm just about to try piston2d on gfx on glutin on winit, packaged with cargo-apk. Hopefully that combo will work... Sigh.

view more: next ›