I have some concerns related to
https://github.com/rust-lang/rust/issues/18699 and I'd like to get some
advice from the team.
Support for cross-compiling code with plugins was broken for a few months
now for anything but linux. Finally it seems to be broken for linux as well
halting all our
second attribute, lol, possibilities are endless.
But indeed unsafe is likely only, currently, for memory safety.
Still I like the idea! I love the idea. I read your email earlier today
but only shortly ago I realize what you mean.
On Jan 1, 2015 5:17 AM, Vladimir Pouzanov farcal...@gmail.com
which uses the same instruction for any ARM device, may be that was
patched in upstream, may be not. You can also ask Vladimir Pouzanov and
zinc.rs [2] team, AFAIK they had the similar problem too and definitely
have a workaround.
[1]
https://github.com/rust-lang/rust/blob/master/src
Hi all.
Is there any way to access compiler warnings and errors other than parsing
stdout? I'd prefer a bit more structured approach.
--
Sincerely,
Vladimir Farcaller Pouzanov
http://farcaller.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
I've just published a tiny test framework: shiny at
https://github.com/farcaller/shiny. It's best used with hamcrest-rust.
This library exists because I find it ugly to redefine all the
initialisation code in every test case and I can't simply move it to a
function due to problems with moving [T]
framework and Hamcrest assertions/matchers
for Rust!
On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko
errordevelo...@gmail.com wrote:
Dude, that's pretty much rspec ;) sweet!
On 22 Jul 2014 20:07, Vladimir Pouzanov farcal...@gmail.com wrote:
I've just published a tiny test framework: shiny
I have a problem figuring the reasonable data access pattern for my code,
here's a brief description. I have a tree structure where each node has a
path and an optional name. Path is used to locate the node in tree
hierarchy, names are stored in a flat namespace as node aliases:
lpx17xx@mcu {
I have a tree of Nodes where each node might have a name. I'm trying to
convert the tree into a HashMap of named nodes, but my code is getting
extremely complex due to the fact that I cannot pass mut HashMap around.
let mut named_nodes = HashMap::new();
let nodes = vec!( ... );
named_nodes =
);
return false;
} else {
map.insert(name.clone(), *n);
}
},
None = (),
}
}
true
}
My failure point was that I didn't realise you cannot access mut while yo
have a reference to anything you pass mut to.
On Sun, Jun 15, 2014 at 8:14 AM, Vladimir
Funnily enough I did the same yesterday. I made a small extension to
https://github.com/indirect/dash-rust, my fork can be found here:
https://github.com/farcaller/dash-rust
It removes the left side navigation panel from docs and adds TOC generation.
On Sat, Jun 14, 2014 at 2:55 AM, Valerii
Rustc runs on arm just fine.
On Mon, Jun 9, 2014 at 11:32 AM, Kevin Cantu m...@kevincantu.org wrote:
Perl and Python may still be dependencies for small things on some
platforms, IIRC, too.
Anyways, to get `rustc` on a new architecture, it must be one LLVM
supports, and then you should
Thanks, I managed to bootstrap my rustc already with a few hints.
On Fri, Jun 6, 2014 at 4:19 PM, Valerii Hiora valerii.hi...@gmail.com
wrote:
I'm trying to run rustc on an arm board, but obviously there's no
precompiled stage0 to build the compiler.
Is there a procedure to cross-compile
I'm trying to run rustc on an arm board, but obviously there's no
precompiled stage0 to build the compiler.
Is there a procedure to cross-compile stage0 on other host machine where I
do have rustc?
--
Sincerely,
Vladimir Farcaller Pouzanov
http://farcaller.net/
, Vladimir Pouzanov farcal...@gmail.com
wrote:
I have a side question related to the same code.
Currently __STACK_LIMIT is constant, but I would like the preamble to
verify
stack overflow for multithreaded context, i.e. __STACK_LIMIT will depend
on
the current running thread. Is there any
I guess I've misread how __STACK_LIMIT works, it seems that I can change
it's value on context switch so that it keeps track of the current running
task. Works flawlessly, so I'm going to proceed with my original patch now.
On Fri, Apr 25, 2014 at 6:33 PM, Vladimir Pouzanov farcal
I have the following setup:
libzinc, compiles as rlib, provides all the stuff
support, compiles as obj, provides __morestack, memset/memcpy and other
required things
libapp, compiles as staticlib emitting obj, depends on libzinc, builds
with lto.
I link libapp.o and support.o to get the
that help your use case, or are you thinking of something more
complex?
On Wed, Apr 30, 2014 at 6:49 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
I have the following setup:
libzinc, compiles as rlib, provides all the stuff
support, compiles as obj, provides __morestack, memset
also had to move __STACK_LIMIT into external C file, as I couldn't define
it as external in one crate and provide it in another crate down the chain.
On Wed, Apr 30, 2014 at 5:29 PM, Vladimir Pouzanov farcal...@gmail.comwrote:
Right, so I have a publicly reachable symbol __STACK_LIMIT inside my
in .rodata, but we
have #[link_section] to deal with that.
* same as above, but use extern with further linker script placement (same
way as I deal with ioregs in zinc).
On Thu, Apr 24, 2014 at 11:37 PM, Ben Gamari bgam...@gmail.com wrote:
Ben Gamari bgam...@gmail.com writes:
Vladimir Pouzanov
with writing tests or taking a peek
at the patch if you want! I'm acrichto on IRC
On Tue, Apr 22, 2014 at 12:43 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
The problem is that mrc is generated unless target is thumb1, but
cortex-m3
is thumb2 that still doesn't support mrc:
http
believe that in the hopes of keeping it as light as possible it
never makes any function calls.
I do agree though, that it's at tricky situation in that case. How
does TLS otherwise work for that platform?
On Fri, Apr 25, 2014 at 8:14 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
I have
On Thu, Apr 24, 2014 at 9:01 AM, Ben Gamari bgam...@gmail.com wrote:
Unfortunately this replaces the ugly possibility of unpredictable
crashes with the slightly less ugly possiblity of unpredictable
deadlocks if we run out of stack in the middle of execution. Perhaps
threads could be
Luckily enough, I had the concept for zinc even before I started coding in
rust :-) And yes, there are lots of different oxides in rust world.
On Wed, Apr 23, 2014 at 3:58 AM, Thad Guidry thadgui...@gmail.com wrote:
Actually...I do not. :)
On Tue, Apr 22, 2014 at 9:05 PM, Chris Morgan
simple, and I think that it might be possible to extend ~T ownership for
something like that.
On Wed, Apr 23, 2014 at 3:47 PM, Ben Gamari bgam...@gmail.com wrote:
Vladimir Pouzanov farcal...@gmail.com writes:
This is the project I've been tinkering with for a good number of
weekends zinc
to submit patch against https://github.com/rust-lang/llvm or send
it to upstream?
On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov farcal...@gmail.comwrote:
Hm, it seems to have precautions to stop mrc from materializing on Thumb1.
I guess I need to take a better look into what's going wrong
This is the project I've been tinkering with for a good number of weekends
— zinc, the bare metal stack for rust is available at
https://github.com/hackndev/zinc.
I've just finished a major refactoring work for LPC1768 code, so STM32F4 is
kind of broken yet, and LPC1114 is totally dropped, but
Starting recently (no more than two weeks), rustc is generating a broken
prologue for arm. Here's the sample assembly:
0x0f44 +0: push {r4, r5}
= 0x0f46 +2: mrc 15, 0, r4, cr13, cr0, {3}
0x0f4a +6: mov r5, sp
0x0f4c +8: b.n 0xa78 main+2616
0x0f4e +10: ands r4, r0
find the initial commit for
support at rust-lang/llvm [2].
[1] -
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html
[2] - https://github.com/rust-lang/llvm/pull/4
On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
Starting recently
I'm working on a proof-of-concept implementation for
https://github.com/rust-lang/rfcs/pull/44 [Linker placement attribute], and
I actually got code that is working, but the outcome is worse than I
expected.
Consider the following snippet:
#[unsafe_override_address]
static Tinst : T = 1000;
Apparently I had a problem of double pointer. The solution was to use
static Tinst : 'static T = 1000;
though I have modified the code now so that T works as well.
On Sun, Apr 20, 2014 at 2:04 PM, György Andrasek jur...@gmail.com wrote:
On Sun, Apr 20, 2014 at 10:46 AM, Vladimir Pouzanov
, Apr 14, 2014 at 10:19 AM, Huon Wilson dbau...@gmail.com wrote:
On 14/04/14 06:12, Vladimir Pouzanov wrote:
I have a number of I/O mapped registers that look like:
struct Dev {
.. // u32 fields
}
pub static Dev0 : *mut Dev = 0xsomeaddr as *mut Dev;
with macro-generated getters
I have a number of I/O mapped registers that look like:
struct Dev {
.. // u32 fields
}
pub static Dev0 : *mut Dev = 0xsomeaddr as *mut Dev;
with macro-generated getters and setters:
pub fn $getter_name(self) - u32 {
unsafe { volatile_load((self.$reg)) }
}
unfortunately, calling a getter
!(do_something(), bits 4 to 8 {
0 = DivideBy1,
1 = DivideBy2,
2 = DivideBy4,
_ = UnknownDivisor
};
On Fri, Apr 4, 2014 at 7:11 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
I've submitted an RFC for this one:
https://github.com/rust-lang/rfcs/pull/29
type T that
implements LCD.
fn fooT : LCD(x : T) { // x's type is T rather than LCD
x.line(); // static dispatch based on type T known at compile-time
}
On Wed, Apr 2, 2014 at 8:32 AM, Daniel Micay danielmi...@gmail.com
wrote:
On 02/04/14 06:25 AM, Vladimir Pouzanov wrote:
If I get
{
spi: S,
...
}
and then:
implS: SPI LCDS {
...
}
On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov farcal...@gmail.com
wrote:
I might have found an unsupported case.
Consider the following:
trait SPI { ... }
struct McuSPI;
impl SPI for McuSPI { ... }
struct
object) doesn't
implement `SPI` (the trait). You would have to explicitly implement
`SPI` for `SPI`. I'm not really sure how to solve this without using
trait objects; you seem to want an inherently dynamically-dispatched
system.
On Tue, Apr 8, 2014 at 2:08 PM, Vladimir Pouzanov farcal
like in C (note: I'm not saying
`T*` and `T[]` are the same type, I know they aren't)
On Sat, Apr 5, 2014 at 6:53 AM, Simon Sapin simon.sa...@exyr.org wrote:
On 05/04/2014 11:39, Vladimir Pouzanov wrote:
The problem is that [extern unsafe fn()] results in 8 bytes, pointer to
the actual
I've submitted an RFC for this one:
https://github.com/rust-lang/rfcs/pull/29
On Sat, Mar 29, 2014 at 6:14 PM, Bill Myers bill_my...@outlook.com wrote:
I think the best solution is to add uN and sN types where N is not a power
of two, which LLVM should already support.
Then you can write
Is it possible to port the following C code to rust?
__attribute__ ((section(.isr_vector)))
void (* const isr_vector_table[])(void) = {
_stack_base,
main, // Reset
isr_nmi, // NMI
isr_hardfault,// Hard Fault
0,// CM3 Memory Management
If I get it right, calls to traits are resolved in runtime (so, traits are
kind of similar to C++ virtual methods).
What I'm proposing here is a compile-time approach.
Let's say we have the following trait:
pub trait LCD {
fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color: u8);
I decided to switch away from Rakefiles (after I switched to them from
Makefiles) and make a dependency generator / build system in rust to get
20% more coolness factor.
Here's a sample config file:
https://gist.github.com/farcaller/4c08908fe526e0631989. As you can see, the
syntax is somewhat
That actually sounds like a good option, thanks!
On Sun, Mar 30, 2014 at 11:22 PM, comex com...@gmail.com wrote:
On Sun, Mar 30, 2014 at 8:08 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
gpio::Pin::new(0, 15, gpio::Out, gpio::UART1_TXD); // p13 - TXD
compiles, but something like
I'd like to propose to extend the language with some concepts from nesC,
which is a nice but quite unknown C superset outside of TinyOS world.
The concept would allow better static polymorphism and better code
optimisations and is loosely based on nesC modules/components. It might be
possible to
readable.
Well... Maybe it's time to do some big macro for matching all the stuff and
hope that compiler will optimise it anyway.
On Sun, Mar 30, 2014 at 10:12 AM, Simon Sapin simon.sa...@exyr.org wrote:
On 30/03/2014 09:50, Vladimir Pouzanov wrote:
I have a chunk of code that toggles different
, gpio::SPI_MISO); // p13 - TXD
would fail, because there's no SPI_MISO defined for port 0 pin 15.
On Sun, Mar 30, 2014 at 11:41 AM, Simon Sapin simon.sa...@exyr.org wrote:
On 30/03/2014 10:30, Vladimir Pouzanov wrote:
That shifts the issue even more into runtime, doesn't it?
My goal
There's one thing that I often have to deal in embedded code — doing match
on a few bits from an I/O register, which is commonly u32:
let val : u32 = ...;
match (val 0b11) 6 {
0b00 = ...,
0b01 = ...,
0b10 = ...,
_ = {}
}
You can clearly see two problems here: I need to provide a
to catch
those type of errors!
- Clark
On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov farcal...@gmail.comwrote:
There's one thing that I often have to deal in embedded code — doing
match on a few bits from an I/O register, which is commonly u32:
let val : u32 = ...;
match (val 0b11
I'm trying to experiment with rust and some embedded code. Currently I have
to do a three-pass compilation:
rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc
llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o main.s
arm-none-linux-gnueabi-as main.s -o main.o
First,
Nevermind, I lost -O somewhere in between copying and pasting command line
flags. Optimised version doesn't have any morestack references (which is
strange concept though).
On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov farcal...@gmail.comwrote:
Figured out I can use --target thumbv6m
rustc to generate freestanding code given some additional
options?
On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov farcal...@gmail.comwrote:
Nevermind, I lost -O somewhere in between copying and pasting command line
flags. Optimised version doesn't have any morestack references (which
to
just compile the IR yourself (the stack checking is a target-specific
machine pass, which is why it shows up with --emit asm but not --emit
bc)
On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov farcal...@gmail.com
wrote:
So it doesn't work in the end.
rustc --emit bc with flags set
51 matches
Mail list logo
