kam

You can filter by category. https://500px.com/popular/landscapes

The size of a binary statically-linking libstd and targeting a desktop OS has nothing to do with the size of a binary targeting a bare-metal microcontroller where you use only libcore. If you compile for a MCU target with MCU-style code, your code size will be in the same ballpark as the equivalent C++.

Yet you post on a site called Hacker News.

Nope, LLVM doesn't have a backend for the Xtensa architecture.

The author of this guide (Jorge Aparicio) has done an amazing amout of work getting the ecosystem started for Rust on microcontrollers. A few of his other projects worth mentioning:

- svd2rust (https://docs.rs/svd2rust/) generates register-level APIs from SVD files, an XML format provided by most ARM microcontroller vendors. This gets you the equivalent of the low-level C header files for manipulating the hardware registers.

- cortex_m (https://docs.rs/cortex-m/), which provides APIs for the core ARM peripherals in every Cortex-M MCU.

- f3 (https://docs.rs/f3/) - High level APIs for the peripherals and external sensors on the STM32 F3 Discovery board.

> Above guide uses inline assembly to blink a GPIO.

No, the only inline ASM in this guide is to cause a debugger breakpoint. You also need inline ASM to enable/disable interrupts, and that's about it.

The code in this guide looks ugly because it's written to show how to use the hardware without any abstraction. Higher level APIs like f3 (https://docs.rs/f3/0.3.1/f3/) exist, though not nearly for every chip or peripheral. Even in C, for anything outside the popular Arduino/mbed/etc boards, your choice is usually between buggy vendor bloatware and using the registers directly after carefully reading the datasheet.

It doesn't need to hunt for the directory entry, just needs to call `fstat()` on the stdin file descriptor.

https://www.reddit.com/r/rust/ and https://this-week-in-rust.org/

> The site had its original URL removed, but you can still find it easily.

Why isn't this a link? Why isn't there a link to http://sci-hub.cc/ anywhere in this article? Linking isn't illegal.

I've used Rust on a variety of ARM Cortex-M based microcontrollers including Atmel SAMD21, NXP LPC1830, and STM32F4. AVR is tougher because that's an 8-bit architecture with very new support in LLVM.

On microcontrollers, you use libcore instead of the full libstd, for lack of an OS or memory allocator. Libcore is easy to cross compile because it has no dependencies. You provide a target JSON file to specify LLVM options, and a C toolchain to use as a linker, and nightly rustc can cross-compile for platforms supported by LLVM.

https://github.com/hackndev/zinc is a good starting point.

Things like interrupt handlers and statically-allocated global data require big chunks of unsafe code. Rust has a promising future in this space, but it will take more experimentation to get the right abstractions to make microcontroller code more idiomatic.

Atom with linter-rust highlights compile errors: http://i.imgur.com/ac7FTpW.png

Or do you have a more specific visualisation for moves/ownership in mind?

The use of the iCE40 family is exciting because there's a fully open source verilog to bitstream synthesis toolchain for the iCE40HX1K.

https://github.com/cseed/arachne-pnr

http://www.clifford.at/icestorm/

https://github.com/cantino/reckon imports CSV to Ledger, with Bayesian automatic categorization.

Rust will be supported by the tools the same way JS is. `tessel push` will run the cross compiler, and Rust libraries will be provided to access the hardware and modules.

Yes, you can get to the underlying Linux system and run anything you want (including Lua), but the point is to abstract away the OS so you only have to think about your code and the hardware.

[1996] according to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.9...

Yeah, it's unclear what he's talking about there. Normally when a function allocates a new object, it would want to return it by move (transferring ownership), rather than by reference. That doesn't involve any lifetimes.

    fn make_a_foo() -> Box<Foo> {
        Box::new(Foo { a: 5 })
    }

If the function allocated memory and only returned a borrowed reference, who would be responsible for freeing it? Yes, Rust will make you stop and think there, as it enforces memory safety.

In cases where it does make sense to return a reference to a new object, like allocating from an arena, the lifetime ('a) of the returned reference will be the same as the lifetime of the arena.

    fn new_from_arena<'a>(arena: &'a TypedArena<Foo>) -> &'a mut Foo {
        arena.alloc(Foo { a: 5 })
    }

But Rust can infer the lifetime, so that can be shortened to:

    fn new_from_arena(arena: &TypedArena<Foo>) -> &mut Foo {
        arena.alloc(Foo { a: 5 })
    }

The Xen pre-disclosure list is public, and Rackspace is on it:

http://www.xenproject.org/security-policy.html

They also spell out the policy for who is eligible.

They cite RFC6920 [1], which uses the "host" portion of the URL as an optional "authority" field.

[1] http://tools.ietf.org/html/rfc6920#section-3

That's why they're all squared.

Which is, of course, assuming that none of the equations involve imaginary numbers.

Yes. The module ports are documented here: https://github.com/tessel/hardware/blob/master/tessel-hardwa... and the JS APIs for using them here: https://tessel.io/docs/hardwareAPI

It doesn't matter. Without a legally-binding pledge limiting the patents to be used only defensively, there is a chilling effect on innovators in the space. The threat of a lawsuit discourages development and investment.

> Rust will never have an Intel-compiler.

Yesterday, Intel announced a project combining a clang frontend with icc's backend. [1] The backend takes LLVM IR, so hopefully Rust's LLVM IR output could be run through it.

[1] https://news.ycombinator.com/item?id=7663462

Rust can use C libraries pretty easily, and there's a tool to autogenerate Rust `extern` declarations from C headers: http://static.rust-lang.org/doc/master/guide-ffi.html https://github.com/crabtw/rust-bindgen

> I’m not a fan of printf()-style parameters, because they break ordering (remarkably, php does this best with its “.” and “$” notations).

Rust's println! macro also supports named format parameters, which don't need to be in the same order as the format string.

    println!("{foo}: {bar}", bar=5, foo="abc");

> It seems that move semantics distinguish between objects and primitives, instead of everything being an object?

Structs fulfilling the Copy trait (meaning they don't have destructors and can be duplicated with a simple memcopy) have the same copy semantics as primitive number types.

> Forcing the programmer to manually place values on the heap with “~” is annoying, when other languages can automatically optimize such things. > Lifetimes completely confuse me, as it seems like they would be handled by garbage collection?

Rust is a systems language. The language makes memory allocation and management explicit, by design. Lifetimes allow Rust to provide memory safety at zero run-time cost. They're how the programmer proves to the compiler that pointers are valid at the time of use. There is no garbage collection by default; only when you use the Rc or Gc types from the library.

I've seen it labelled "washes away bacteria".

SourceMap.

Google's "off the record" has nothing to do with the OTR protocol. It only instructs the server to stop archiving the conversation, and does not involve end-to-end crypto. Google still has access to the cleartext as it passes through their servers.

SEEKING WORK - Remote (Based in Colorado, USA)

I write code for both sides of the HTTP request as well as both sides of the USB cable. My current project involves d3.js, node, LLVM, and custom hardware. Somewhere between frontend and embedded, there's probably something I can build for you.

I primarily work with:

    - HTML5, JavaScript (CoffeeScript), CSS, jQuery, Backbone
    - NodeJS, Python, Flask
    - C, C++, Linux, Git
    - PCB design, AVR & ARM microcontrollers
    - among many more

See some of my projects at http://kevinmehall.net. Shoot me an email: hnfreelance@kevinmehall.net

SEEKING WORK - Remote (USA, American Citizen)

I go a little beyond what they call "full stack". I write code for both sides of the HTTP request as well as both sides of the USB cable. My current project involves d3.js, node, LLVM, and custom hardware. Somewhere between frontend and embedded, there's probably something I can build for you.

I primarily work with:

  - HTML5, CSS (LESS), JavaScript (CoffeeScript), jQuery, Backbone
  - NodeJS, Python, Flask
  - C, C++, Linux, Git
  - PCB design, AVR & ARM microcontrollers
  - among many more
 

See some of my projects at http://kevinmehall.net, and shoot me an email: hnfreelance@kevinmehall.net