Re: [rust-dev] FYI: C stacks

2011-09-30 Thread Marijn Haverbeke
Backtraces do seem to work on the Mac GDB, once it's appropriately patched Is this patch in upstream gdb? Ubuntu currently comes with gdb 7.2. Can I expect that to work, or should I build a patched on myself? ___ Rust-dev mailing list

Re: [rust-dev] Proposal: Java-style iterators

2011-09-30 Thread Patrick Walton
On 9/29/11 11:00 AM, Graydon Hoare wrote: - Write 1 iter interfaces on most collections, with varying strategies, to reduce unwanted boilerplate in cases you don't need it. Cold code is cold, harmless. vec::each(v) == takes fn(e) - (), returns () vec::scan(v) == takes fn(e) - bool, returns ()

Re: [rust-dev] Parameter passing and native calls

2011-09-30 Thread Patrick Walton
On 9/30/11 12:14 AM, Marijn Haverbeke wrote: Now that every parameter is passed by reference, our ABI is no longer compatible with C. Are you talking about calling C functions from rust, or calling rust from C? In the first case, we are generating a wrapper anyway, which currently makes sure

Re: [rust-dev] Parameter passing and native calls

2011-09-30 Thread Patrick Walton
On 9/30/11 8:37 AM, Patrick Walton wrote: On 9/30/11 12:14 AM, Marijn Haverbeke wrote: Are you talking about calling C functions from rust, or calling rust from C? In the first case, we are generating a wrapper anyway, which currently makes sure things are passed by value. Not anymore, with

Re: [rust-dev] Proposal: Java-style iterators

2011-09-30 Thread Graydon Hoare
On 30/09/2011 8:29 AM, Patrick Walton wrote: I whipped up a small testcase using clang and it seems that LLVM indeed can optimize this style of iteration into a loop. Is everyone ok with this? Oh also note: you almost certainly want to make the traling-block-as-last-arg syntax work before

Re: [rust-dev] Parameter passing and native calls

2011-09-30 Thread Marijn Haverbeke
Not anymore, with the C decl. Can you elaborate on that? How about what I proposed earlier: the '+' sigil means by-value, the '' sigil means by-immutable-reference, and leaving it off has the compiler choose a sensible default based on the type? That'd work, though it'd be a little obscure

Re: [rust-dev] Proposal: Java-style iterators

2011-09-30 Thread Graydon Hoare
On 30/09/2011 10:00 AM, Marijn Haverbeke wrote: I'm also fine with this. As for the syntax... vec::each(v) {|e| ... } This once again produces ambiguity with fail and ret: does 'fail {|e| ...}' mean 'call the function produced by fail with this block', or 'fail with this block as the

[rust-dev] Removing ty_native

2011-09-30 Thread Patrick Walton
I think native types might have outlived their usefulness at this point. We can represent them as ints, and their type safety can be achieved via tags. So native mod ... { type ModuleRef; } becomes tag ModuleRef = int; This has the nice benefit of being able to use sizes other than words;