#tock

/

      • jsgf has quit
      • jsgf joined the channel
      • jsgf has quit
      • jsgf joined the channel
      • jsgf has quit
      • jsgf joined the channel
      • jsgf has quit
      • jsgf joined the channel
      • jsgf has quit
      • jsgf joined the channel
      • jsgf has quit
      • niklasad1 joined the channel
      • jsgf joined the channel
      • jsgf has quit
      • jsgf joined the channel
      • niklasad1 joined the channel
      • niklasad1___ joined the channel
      • niklasad1___ has left the channel
      • Ndushi
        Hi, I would like to contribute to the tockOS project, so I have been looking through some of the code and noticed many places where int are used instead of some algebraic data type, is there a reason for this? I thought rust was supposed to have "zero-cost abstractions"?
      • Are there actucal performance implications or is this something I would be welcome to refactor?
      • alevy
        there shouldn't be any performance implications with swapping `u32` for `enum { Foo, Bar, Baz }`
      • and if there are places where that would work, I think it's better
      • in general, there are probably lots of places where we could be doing that where we don't and that would certainly be a welcome contribution
      • Ndushi
      • and it made me feel bad
      • It looked like a non-intrusive change
      • alevy
        yeah I think that seems reasonable
      • Ndushi
        also, syscalls could potentially be enums as well?
      • but that seems like an intrusive change :D
      • alevy
        syscalls in principle make sense, but since they are basically only used to dispatch methods from a raw `int` it would depend on whether it would make the code cleaner overall. but could be worth a shot as well
      • Ndushi
      • here I would have liked to see
      • alevy
        i think everyone's generally open to anything that makes the code cleaner and more comprehensible without a safety or performance impact. simple enums seem like a good candidate for that
      • Ndushi
        "START" "STOP" "SET_TX_POWER" instead of 0 1 2 3 4 5
      • alevy: great :D
      • a friend and I will probably be working near to full time with tockOS BLE as a master's thesis @ chalmers
      • alevy
        Oh hi! we were just talking about you with Olaf :)
      • Ndushi
        cool :D
      • alevy: is he in this channel?
      • alevy
        cc'ing niklasad1 who is the expert when it comes to BLE on Tock (also a former masters student at Chalmers with Olaf)
      • I don't think Olaf stoops down to IRC unfortunately
      • Ndushi
        that's too bad :D
      • Vagabond_
        +1 to more enums
      • alevy
        we have (mostly) weekly calls and he was updating us on what you might plan to do with BLE
      • Vagabond_ is now known as Vagabond
      • Ndushi
        that's neat!
      • hopefully he didn't over-promise too much :D
      • this is our first foray into rust
      • Vagabond
        Ndushi: do you guys have a MCU picked out?
      • Ndushi
        there's that word again :D
      • what does MCU stand for?
      • alevy
        microcontroller unit
      • I'm guessing you'll use the NRF52, right?
      • Ndushi
        so basically, what hardware unit we're going to use?
      • alevy
        yes exactly
      • Ndushi
        that's the one!
      • we looked for last year's master's thesis on the tockos website, but maybe you don't want to publish it there?
      • alevy
        oh, it's linked from a blog post
      • that's actually up to niklasad1 and friedrich
      • actually if they're comfortable with it being in the publications page, i'd love to post it there
      • Ndushi
        right? I couldn't think of a reason?
      • Vagabond
        Ndushi: We are using the NRF52 as well, we should be making a PR for an i2c driver shortly (we wrote the SPI driver already)
      • Ndushi
        awesome!
      • Vagabond: are you a student or just into it? :)
      • Vagabond
        we are *aiming* to use Tock in a commercial product
      • Ndushi
        are you allowed to discuss details? :D
      • Vagabond
        probably :)
      • Ndushi
        so what kind of product?
      • Vagabond
        a sub-ghz IoT module
      • so the idea with Tock is that the user could put their own userland code on there, or you could put some userland code on there to expose a SPI/I2C/UART interface to some other peripheral
      • and the module would handle the wireless/crypto/etc
      • niklasad1
        hello guys :)
      • Ndushi, good points :)
      • I'm actually done some changes to that https://github.com/niklasad1/tock/blob/ble_virt...
      • Ndushi
        niklasad1: nice!
      • niklasad1
        google "niklas adolfsson rust" and you will find our thesis
      • alevy
        niklasad1: you can let me know separately if you want/don't want it posted on the tock website (or you can just submit a pull request to tock-www if you want)
      • i remember actually thinking about asking you and then forgetting to ask you :/
      • niklasad1
        alevy, you free to publish our thesis on the tockos website if you are comfortable with it
      • Ndushi
        niklasad1: about that, would'nt this work? https://github.com/andersk/enum_primitive-rs
      • niklasad1
        Ndushi, I think that crate depends of the standard library (std) in Rust
      • If I remember correctly
      • Ndushi
        and we cannot do that?
      • Vagabond
        right
      • you can only use stuff that supports no_std
      • niklasad1
        yeah, we only have access to the "core" in the embedded world
      • Ndushi, although that crate seem only to use std::Option from std which is apart of the core as well perhaps it's easy to port
      • alevy
        yeah, it might be simple to port that crate to `no_std`, and if so, the authors may be open to a pull request
      • separately, there is also a discussion going on about how to include external crates without yet having a facility to determine which of our dependencies use `unsafe`
      • niklasad1
        ok, your "safe-haskell" discussion in the SHA-256 PR?
      • alevy
        exactly
      • i don't think this should necessarily preclude us from using external crates for now, but just let's be aware of that is all
      • niklasad1
        BTW, alevy did you post an RFC related to that with Cargo? Would be pretty useful know exactly which dependencies are "unsafe"
      • alevy
        i posted a pre-RFC on rust internals a few months ago. it got mixed feedback and probably needs some work to improve
      • it's also something we could _potentially_ implement ourselves, which might be a useful thing to bring to the table for a cargo RFC (plus we would use it)
      • in principle I think it's simply a matter of calling `rustc` with the right arguments for particular dependencies and parsing rules from Cargo.tomls, but I haven't at all looked into cargo to see how difficult that might be
      • jsgf has quit
      • niklasad1
        damn, many comments..... but the rough sketch sounds good to me
      • jsgf joined the channel
      • jsgf has quit
      • I created a PR to the enum_primitive-rs crate btw the fix was trivial but it seems like Rust 1.0 fails though
      • jsgf joined the channel
      • bradjc[m]
        I believe that it will fail even if you make no changes since the dependency num-traits has updated since the last commit on master.
      • But I think that dependency would also need to change: https://github.com/rust-num/num/blob/master/tra...
      • ratmice
        alevy: haven't used "tag_safe" lint plugin, but its on my list of things to check out, perhaps it does something like what you want?
      • niklasad1
        bradjc[m], thanks ..... but why do they rely on std when for example std::ops:Add when core::ops:Add exist?
      • *why do they rely on std::ops:Add when core::ops::Add exist? (sorry bad sentence)
      • alevy
        ratmice thanks for the pointer, I hadn't heard of that
      • bradjc[m]
        i think a better question is why does rust allow you to do this and make this a problem for developers
      • thanks, rust
      • i guess the question is does everything just work if someone uses `std::` but then only uses something that is just a re-export of `core::`
      • that would make this easier to swallow
      • and would save us from PR'ing every dependency we want to use
      • niklasad1
        :) great
      • alevy
        i believe the answer is no
      • because the dependency resolver in cargo would notice that the crate requires `std` and try to find one (which we don't provide)
      • bradjc[m]
        it should special case this!
      • alevy
        there are probably ways to fake this, but really i think this is an ecosystem problem (like, we really should be good stewards and PR a bunch of libraries to use `no_std` if they can)
      • i think, in part, this may have been because `no_std` was feature gated and maybe only available in nightly for a while. but i believe that's changed
      • so now it's "good" to mark your library `no_std` if you can, but it used to not be reasonable if you wanted to support stable Rust
      • (I think what I'm saying is true)
      • bradjc[m]
        it would be good if there is a rust page that says to use only core if you can
      • because that SO result is the only thing that i find, and it clearly says to use std
      • ppannuto[m]
        yeah, this comment is slightly concerning: https://stackoverflow.com/questions/35951024/st...
      • bradjc[m]
        does actually including `#![no_std]` matter?
      • for us in particular
      • alevy
        yes. by default, rust implicitly assumes a crate depends on `std`
      • bradjc[m]
        is it enough that `std` isn't used?
      • alevy
        so you need that to tell the compiler you don't need it
      • bradjc[m]
        oh come on
      • alevy
        it may be enough in theory
      • bradjc[m]
        this is seeming less and less like an ecosystem problem
      • alevy
        :) bradjc[m] I think designing the infrastructure around a language is a tad bit more challenging than you're making it out to be
      • bradjc[m]
        wasnt it the rust developers who said that embedded was a priority for rust?
      • alevy
        sure. that doesn't mean they can anticipate all our pains
      • there indeed might be remedies that the compiler or cargo could help with. it might be worth asking or suggesting to them
      • e.g. on IRC or internals.rust-lang.org or something
      • i don't know that they are very a tune to embedded development even if they are interested in supporting it
      • bradjc[m]
        so what do we do? not bother with using external crates? hope that developers are ok with `no_std` and don't know about the backwards compatibility pitfall and make PRs to libraries we want to use? try to get cargo/rustc to change?
      • alevy
        Yes exactly ;)
      • We have issues using external crates anyway without a way of tracking use of unsafe, so that's a journey
      • And then yes, I think the rest requires that we are vocal about the benefits of prioritizing no_std
      • This is what, I believe, you professors call "impact"!
      • bradjc[m]
        haha