These are chat archives for rust-lang/rust

15th
Jan 2018
Techcable
@Techcable
Jan 15 2018 00:40
@dunnousername Yes, wrapping implements all arithmetic operations as delegates and returns a Wrapping result.
dunnousername
@dunnousername
Jan 15 2018 00:41
Will it cast it all to a u8 and not a wrapping::<u8>?
Techcable
@Techcable
Jan 15 2018 00:41
@dunnousername You have to explicitly access the inside with the .0 at the end
@dunnousername Although I don't think it's recomended, you're allowed to turn overflow checks off by passing -C overflow-checks=val to the compiler
dunnousername
@dunnousername
Jan 15 2018 00:44
I will try that. Now I'm implementing a malloc() using a Tree with enums and fun things. It's way more fun than it is actually functional
Techcable
@Techcable
Jan 15 2018 00:45
Good luck with that, you're going to need it when dealing with unsafe code!
dunnousername
@dunnousername
Jan 15 2018 00:46
There are probably more unsafe blocks than if statements
It's so hard not using Vec, haha
Techcable
@Techcable
Jan 15 2018 00:46
:laughing: I know the feeling!
dunnousername
@dunnousername
Jan 15 2018 01:37

I have some code in a constructor:

return Tree {
[...]
layer: [[Growing(level); 32]; 24]
[...]
};

layer is a 2D array, and I want level to refer to the depth of the 'outer' dimension. Is there any way to do this, with closures or something? It is 24 levels deep, and that is a lot of space.

So, layer[1][anything] == Growing(1), layer[2][anything] == Growing(2), etc.
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:20
@dunnousername I'm not aware of any way to do that when working with fixed-size arrays. Easiest is maybe just to write a for loop to set the values afterwards.
dunnousername
@dunnousername
Jan 15 2018 03:21
I ended up using the core macro include!. Does that mess stuff up with Cargo/Xargo though?
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:21
No idea
dunnousername
@dunnousername
Jan 15 2018 03:22
I ended up making my malloc use a recursive Tree, and it hurts my head so muuuch haha
Especially when you name the types Leaves, Branch, Branching, and Growing
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:23
That's an interesting approach. Sounds fun
dunnousername
@dunnousername
Jan 15 2018 03:23
It's like 200 lines and 40% is comments of scratchpad trying to understand what I wrote
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:24
Are you putting the code up somewhere?
dunnousername
@dunnousername
Jan 15 2018 03:25
Not sure, I just git clone'd some code and added a bunch of messy just-about-working-or-maybe-not code to it. It's an OS, and I really didn't want to write a makefile :P
Never actually worked with Rust before, so it's a much steeper learning curve when you do something super low level like this haha
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:27
Oh nice, seems like you're figuring it out pretty quick though!
dunnousername
@dunnousername
Jan 15 2018 03:27
Yea, I really like learning... this is the 3-day weekend before high school midterms... rethinks about studying
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:28
Haha yes, school deadlines are sometimes a great motivator for working on side projects, much to my own detriment
dunnousername
@dunnousername
Jan 15 2018 03:29
I've never written more than 50 lines of code in 24 hours, now I've written about 400
I wonder if it will actually let me write 0 as *mut T
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:32
maybe, but core::ptr::null_mut() is preferable
dunnousername
@dunnousername
Jan 15 2018 03:34
Does that panic on deref? Also, I need my function to return a *mut T
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:36
It should segfault, not panic - we're in unsafe territory. If you need to specify the type explicitly (usually not required), then you can do null_mut::<T>()
dunnousername
@dunnousername
Jan 15 2018 03:38
How can it segfault if it's in core without any way to even print text or syscall? I'm not sure what it would do on bare-metal code, either way
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:39
Right, on embedded hardware, 0 might even be a valid memory address!
Probably depends on your chip
dunnousername
@dunnousername
Jan 15 2018 03:39
If I hide my keys there, nobody can enter my house!
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:41
Well, except for everyone else who lives in the same hardware :P
dunnousername
@dunnousername
Jan 15 2018 03:44
I think I need to somehow compute log2(n) without floating point enabled to turn a physical address into a TreeElement. It's like two arrays, one of linked lists and to the other array, which is linked lists back to the first array.
Definitely an interesting implementation
This is gonna suck to debug
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:51
dunnousername
@dunnousername
Jan 15 2018 03:51
I can't believe I hadn't figured that out. I probably need more sleep...
Noah Weninger
@nwoeanhinnogaehr
Jan 15 2018 03:53
Check out the other methods below that for even more mindfuck
dunnousername
@dunnousername
Jan 15 2018 03:54
I wonder if it has the IEEE 754 inverse square root... that may come in useful when I have to- wait, I don't have floating point...
dunnousername
@dunnousername
Jan 15 2018 04:51
Is there a way to make a panic call another function (I know this is a bad idea, but panic isn't helpful, as I can't see the error code) instead of crashing? I want to turn the message into a string, then run it through a serial terminal or something
Aleksey Kladov
@matklad
Jan 15 2018 07:15
@dunnousername you might be looking for https://doc.rust-lang.org/beta/std/panic/fn.set_hook.html
dunnousername
@dunnousername
Jan 15 2018 07:49
I eventually figured it out, there is a github issue in the docs at rust-lang/rust#33677
Now I can see what is panicking and why, but for some reason when I do the operation let z = ((ptr as usize) - (0x04000000 as usize)) / 32 I get an integer underflow. It is guaranteed that ptr >= 0x04000000, so I don't get why. When I try to use it in array bounds, I get (with my new fancy error logger): core::fmt::Arguments => index out of bounds: the len is 1024 but the index is 576460752301326336
The errors never stop, I just don't get why all this happens. Is it supposed to be this counter-intuitive coming from JavaScript and C? I must be failing at some major aspect of the language...
Aleksey Kladov
@matklad
Jan 15 2018 07:54

It is guaranteed that ptr >= 0x04000000

Might be useful to add assert!(ptr >= 0x04000000) there ;)

dunnousername
@dunnousername
Jan 15 2018 07:58
Woah... that assertion failed somehow...
Mind blown
Aleksey Kladov
@matklad
Jan 15 2018 07:59
Hehe, there's a reason why integer overflow traps in debug =P
dunnousername
@dunnousername
Jan 15 2018 07:59
This integer overflow is getting me a lot today
I don't want the checks, then the checks save me
It's a null pointer somehow, even though I'm pretty sure I never use 0x0 in my code... weird
blankhart
@blankhart
Jan 15 2018 21:04
i am getting an import error and i can't figure out what i am doing wrong. the project is supposed to have a library and multiple binaries
the directory structure is cargo-standard, lib.rs has the statement pub mod leonhard, there is a directory leonhard under src, the file src/leonhard/mod.rs contains the statement pub mod prime_factors;, there is a file src/leonhard/prime_factors.rs with the module code
Cargo.toml has [lib] name = "leonhard" and the binary code says extern crate leonhard; use leonhard::prime_factors::*;
cargo/rustc can find leonhard but not prime_factors - i get error[E0432]: unresolved import leonhard::prime_factors
at this point i am just staring at it with no new ideas
Jonas Platte
@jplatte
Jan 15 2018 21:09
@blankhart Your libraries root is src/lib.rs. The prime_factors module should be available as leonhard::leonhard::prime_factors to your binary.
blankhart
@blankhart
Jan 15 2018 21:10
that worked, thanks!
Jonas Platte
@jplatte
Jan 15 2018 21:11
If you want your binary and library code to be in separate directories, there are two more common ways of achieving that AFAIK.
(because you don't make put a module that's named just like the crate)
blankhart
@blankhart
Jan 15 2018 21:12
when you say the libraries root is src/lib.rs does that mean that every module i declare will be a name inside whatever name i declare in cargo.toml?
so the first leonhard is from cargo.toml and the second one is for the module in src/lib.rs?
Jonas Platte
@jplatte
Jan 15 2018 21:12
Yeah
blankhart
@blankhart
Jan 15 2018 21:13
i am not aware of a full example project anywhere in the cargo documentation that shows how a big project is organized
there may be abstract statements and guidelines, but an example would be very useful
Jonas Platte
@jplatte
Jan 15 2018 21:13
So to avoid the double leonhard namespace you could either just put everything in the src/leonhard directory into src and everything from src/leonhard/mod.rs to src/lib.rs
Which obviously means that you have both library and binary modules in the same directory though
If you don't want that there are a couple of options
blankhart
@blankhart
Jan 15 2018 21:14
i don't want that
Jonas Platte
@jplatte
Jan 15 2018 21:15
You could have the library code directly in src, and the binary code in src/bin/leonhard (including main.rs)
This is the solution you'd usually use when you have multiple binaries
Any directory in src/bin will be treated as its own binary crate (IIRC)
I think you might also be able to put your binary code directly into src/bin
blankhart
@blankhart
Jan 15 2018 21:16
that is where i have it now
i think that was the structure promoted by the cargo docs
Jonas Platte
@jplatte
Jan 15 2018 21:17
Because with the previously mentioned solution, you'd have to specify --bin leonhard in every cargo command you want to be for the binary
blankhart
@blankhart
Jan 15 2018 21:19
yes that is what i meant when i said the project had the standard layout
Jonas Platte
@jplatte
Jan 15 2018 21:19
The other solution I was thinking about was the setting the path attribute for your [lib] block, to have lib.rs and the rest of your library code somewhere else than directly in src: https://doc.rust-lang.org/cargo/reference/manifest.html#configuring-a-target
blankhart
@blankhart
Jan 15 2018 21:20
there isn't really anything in the layout explanation that makes clear the point you explained lucidly above
Jonas Platte
@jplatte
Jan 15 2018 21:20
Of course you can also combine these, don't have a src directory at all if you want to e.g. have lib and bin instead (though I do think bin would be a misleading directory name for your use case) by specifying path on both blocks, and so on
blankhart
@blankhart
Jan 15 2018 21:20
but maybe it was an idiosyncratic mistake of mine - i suppose if it were just a library project it would have been obvious
Jonas Platte
@jplatte
Jan 15 2018 21:20
What do you mean? Which part isn't covered in the docs?

The thing about src/bin/main.rs is covered in the second paragraph of the section I linked to first:

Cargo will also treat any files located in src/bin/*.rs as executables. If your executable consists of more than just one source file, you might also use a directory inside src/bin containing a main.rs file which will be treated as an executable with a name of the parent directory.

Wait, actually; I misread
src/bin/main.rs isn't supported ^^°
I suppose it would be pretty weird if creating src/bin/main.rs changed how the other files in the directory are compiled
blankhart
@blankhart
Jan 15 2018 21:24
yeah i don't have that, and i guess i was just confused based on my own history of navigating through the module system
Jonas Platte
@jplatte
Jan 15 2018 21:25
You don't have what?
blankhart
@blankhart
Jan 15 2018 21:25
src/bin/main.rs
Jonas Platte
@jplatte
Jan 15 2018 21:26
Ah, okay
blankhart
@blankhart
Jan 15 2018 21:28
i was moving from a library-only project where the code being executed was run as tests, and ditched that because all the error messages printed twice, to a multiple-binary project, and just didn't have a complete worked example or the mental capacity to think through how the module system should work abstractly. but looking back it seems intuitive
do you know if there is a way i can turn on compiler features or flags for all the multiple binaries?
like #![allow(dead_code)] but not have to put that at the top of every executable file
Jonas Platte
@jplatte
Jan 15 2018 21:30
Not that I'm aware of, no
blankhart
@blankhart
Jan 15 2018 21:30
thanks so much for your help!