Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
To complete my understanding: is there a reason a 'sufficiently smart
compiler' in the future couldn't do this conversion implicitly?
I.e. if a function takes a borrowed reference to a container of pointers,
could the compiler ignore what type of pointers they are (because they
won't be going out of scope)?
Thanks,
Phil
On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/23/14 12:11 AM, Phil Dawes wrote:
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
Why not change the signature of `search_crate` to take `~str`?
Patrick
Hi Patrick,
The main reason I haven't done this is that it is already used from a
bunch of places where a path is [str] as the result of an earlier
split_str(::)
e.g.
let path : ~[str] = s.split_str(::).collect();
...
search_crate(path);
Ah, I see. Well, in that case you can make a trait (say, `String`), which
implements a method `.as_str()` that returns an `str`, and have that trait
implemented by both `str` and `~str`. (IIRC the standard library may have
such a trait already, for `Path`?)
You can then write:
fn search_crateT:String(x: [T]) {
...
for string in x.iter() {
... string.as_str() ...
}
}
And the function will be callable with both `str` and `~str`. Again, I
think the standard library has such a trait implemented already, for this
use case.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
It would be necessary (but not sufficient*) for them to have the same
in-memory representation, and currently ~str and str don't.
~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
vector with the length and capacity stored inline, i.e. one word; str
is just `{ data: *u8, length: uint }`, a pointer to a chunk of memory
along with the length of that chunk, i.e. two words.
(*E.g. std::cell::Celluint and uint have the same in-memory
representation, but coercing a [uint] to a [Celluint] is a very bad
idea... when it would theoretically be possible relates to
subtyping/type variance.)
Huon
On 24/03/14 17:36, Phil Dawes wrote:
To complete my understanding: is there a reason a 'sufficiently smart
compiler' in the future couldn't do this conversion implicitly?
I.e. if a function takes a borrowed reference to a container of
pointers, could the compiler ignore what type of pointers they are
(because they won't be going out of scope)?
Thanks,
Phil
On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
On 3/23/14 12:11 AM, Phil Dawes wrote:
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton
pcwal...@mozilla.com mailto:pcwal...@mozilla.com
mailto:pcwal...@mozilla.com mailto:pcwal...@mozilla.com
wrote:
Why not change the signature of `search_crate` to take `~str`?
Patrick
Hi Patrick,
The main reason I haven't done this is that it is already used
from a
bunch of places where a path is [str] as the result of an
earlier
split_str(::)
e.g.
let path : ~[str] = s.split_str(::).collect();
...
search_crate(path);
Ah, I see. Well, in that case you can make a trait (say,
`String`), which implements a method `.as_str()` that returns an
`str`, and have that trait implemented by both `str` and `~str`.
(IIRC the standard library may have such a trait already, for `Path`?)
You can then write:
fn search_crateT:String(x: [T]) {
...
for string in x.iter() {
... string.as_str() ...
}
}
And the function will be callable with both `str` and `~str`.
Again, I think the standard library has such a trait implemented
already, for this use case.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Vector length specified by enum
Hi List,
First off, this came up today when I started on a set of rust bindings for
libgit2. I skimmed around, but if anyone else is working on the same thing,
let's combine effort.
To my point:
I'm writing bindings by hand instead of using bindgen for now to get a better
feel for rust.
I have this struct (Snipped for brevity) with it's C counterpart commented:
struct Repository {
_odb:*u8, // git_odb *_odb;
// ...
cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] // git_cvar_value
cvar_cache[GIT_CVAR_CACHE_MAX];
}
Where GIT_CVAR_CACHE_MAX is the final element in enum git_cvar_cached. With a
similar enum in rust land:
enum GitCvarCached {
GIT_CVAR_AUTO_CRLF = 0, /* core.autocrlf */
// ...
GIT_CVAR_CACHE_MAX
}
I get a compile error:
src/repository.rs:24:17: 24:54 error: expected constant expr for vector length:
non-constant path in constant expr
src/repository.rs:24 cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] //
git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX];
This seems to me like it should work. The value of that enum is a compile and
(if I'm reading the docs surrounding enums correctly) run time constant.
My 2(ish) questions are:
1. Should this work?
and then either:
2. Should I work on a patch to make it work?
or
2. How would I idiomatically write this, since I think I saw on IRC today
there's also no neat way to get the length of an enum either.
Cheers
richo
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How do I pass -march down to llvm from rustc?
You are right in that the __morestack function is a requirement from enabling segmented stacks in LLVM. While we no longer use truly segmented stacks, we still use the segmented stack prologue in order to detect stack overflow. This is a crucial piece of infrastructure for rust code used to ensure safety. It's difficult to provide a __morestack implementation for all platforms, however (as you've discovered), and we're thinking of possibly adding an option to disable split stacks globally (the function prologue), or moving to an alternative scheme which requires fewer runtime dependencies. On Sun, Mar 23, 2014 at 11:48 AM, Vladimir Pouzanov farcal...@gmail.com wrote: Thanks for links to bugs. Is there anything to read on the whole morestack thing? I thought that it's connected to segmented stacks that are (are they?) going away. It seems that I can use #[no_split_stack] before each and every function to generate a valid freestanding binary. If I just could use that in header... On Sun, Mar 23, 2014 at 6:24 PM, Corey Richardson co...@octayn.net wrote: No. See https://github.com/mozilla/rust/pull/8955 and https://github.com/mozilla/rust/issues/11871 for discussion. You can stub out morestack but that won't remove the stack size checks. It's sanest 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 for cortex-m0 provides exact same bc with only difference in target triple (which makes perfect sense) However, replacing llc step with rustc --emit asm provides a different assembler file, which requires __morestack. Should I expect rustc to generate freestanding code given some additional options? On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov farcal...@gmail.com wrote: 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.com wrote: Figured out I can use --target thumbv6m-linux-eabi, which implies -mthumb. Now the problem is that if I use rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o instead of three-step process I mentioned before, I get a valid object file for cortex-m0, but functions have big prologues and symbol table is much bigger: U STACK_LIMIT U _GLOBAL_OFFSET_TABLE_ D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E 0008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E 0004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E 0078 t _ZN4main10__rust_abiE t _ZN4wait20h53ffb23463e08f19Maa4v0.0E U __aeabi_unwind_cpp_pr0 U __morestack 004c T main vs. D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E T main in the initial version. Also, I now need to provide __morestack (no idea what's that about). On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton a...@crichton.co wrote: You should be able to assemble standalone objects for any triple through rustc itself, you'll likely have to specify a different linker or assembler though: rustc foo.rs --target arm-non-linux-gnueabi \ -C linker=arm-non-linux-gnueabi-ld \ -C ar=arm-non-linux-gnueabi-ar As you discovered, you can pass through arguments to LLVM via the -C llvm-args=foo command line option to rustc. If you get complaints that it's an unknown command line argument, it's LLVM telling you those complaints, not rustc. On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov farcal...@gmail.com wrote: 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, I'm not sure how relevant is --target flag for rustc. I seems to change target datalayout/triple in generated bc, but that should be overriden by llc -mtriple anyway, right? Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with rustc: Unknown command line argument '--march=thumb'. Any hints on how can I drop explicit llc and as steps here? -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org
Re: [rust-dev] Vector length specified by enum
On 3/24/14 2:45 AM, Richo Healey wrote: I get a compile error: src/repository.rs:24:17: 24:54 error: expected constant expr for vector length: non-constant path in constant expr src/repository.rs:24 cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; This seems to me like it should work. The value of that enum is a compile and (if I'm reading the docs surrounding enums correctly) run time constant. Can you use `[GitCvarValue, ..GIT_CVAR_CACHE_MAX as uint]`? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
Nope; we can't use casts of enum values in type signatures. This is discussed in https://github.com/mozilla/rust/issues/5873 . Cheers, Josh On 24 March 2014 11:26, Patrick Walton pcwal...@mozilla.com wrote: On 3/24/14 2:45 AM, Richo Healey wrote: I get a compile error: src/repository.rs:24:17: 24:54 error: expected constant expr for vector length: non-constant path in constant expr src/repository.rs:24 cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; This seems to me like it should work. The value of that enum is a compile and (if I'm reading the docs surrounding enums correctly) run time constant. Can you use `[GitCvarValue, ..GIT_CVAR_CACHE_MAX as uint]`? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Which installation options are actually required?
Thanks, Ben. Sounds like I'm going to need to rethink a few things to make sure --libdir works sanely. I can imagine how it may work correctly right now from a source-only installer. rustc may need some tweaks to make it work more generally. On 03/22/2014 11:49 AM, Ben Noordhuis wrote: On Sat, Mar 22, 2014 at 12:55 AM, Brian Anderson bander...@mozilla.com wrote: I'm in the process of rewriting most of the installation code and I'm at the point where it's almost done, and I'm looking at the options to configure that affect installation destinations and wondering which really must be implemented. configure supports a variety of standard options that impact install directories, most of which we ignore because we have nothing to put into them, and some of which just can't work currently given Rust's installation. The relevant options that might affect Rust's installation are: --mandir - changes where man pages go --libdir - changes where libraries go --rustlibdir - changes the *name* of rust's own directory under lib/ First of all, having `--rustlibdir` as an option is probably just wrong and I don't intend to support it; I don't see any reason to make this configurable. Changing `--libdir` will almost certainly make rustc break since it depends on being able to find the lib directory as a relative path from the bin directory. Packagers will be unhappy about the absence of a --libdir switch. For example, x86_64 Fedora requires that normal libraries are installed to /usr/lib64, not /usr/lib. Finally, `--mandir` is an option that I suspect *actually works* in the current implementation, but I don't know if there's any reason ever to not install to `share/man`. FreeBSD? It has man pages in /usr/man rather than /usr/share/man. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Goto statement missing
On 23/03/14 03:09 PM, Erick Tryzelaar wrote: I've been thinking of a couple alternatives that could make us as fast as a c state machine. The simplest night be to leverage the fact that llvm can optimize certain recursive function calls into tail calls, and lower those into jumps. If we go this route, we could only do this for internal functions with certain properties, so it could be nice to add a `#[tail_call] annotation that'll validate these conditions. It varies per-target and has complex requirements, so checking it isn't really a simple task. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
On 24/03/14 12:32 -0400, Josh Matthews wrote:
Nope; we can't use casts of enum values in type signatures. This is
discussed in https://github.com/mozilla/rust/issues/5873 .
Cheers,
Josh
I continued messing with this last night. Yurume on IRC rightfully pointed
out that having the MAX as a variant of the enum is basically broken by
design, you have a variant that is semantically meaningless, so you either
have to explicitly match ... { MAX = unreachable! } everywhere, or have non
exhaustive patterns.
While I still feel that being able to use scalar enum variants in this
context would *sometimes* be useful, I'm less convinced that this pattern is
a good idea.
That said, how would you feel about a patch such that:
enum FooBar {
foo,
bar,
baz
}
let vec: [u8, .. FooBar::size()];
Potentially with parens ommittted, to convey that there's no runtime
computation?
Cheers
richo
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey ri...@psych0tik.net wrote: let vec: [u8, .. FooBar::size()]; Potentially with parens ommittted, to convey that there's no runtime computation? Not sure if it matters, but another thing one might want to use in a constant expression is sizeof, which wouldn't necessarily be amenable to a similar approach. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
