Re: [rust-dev] Rust discourse visibility [Was: Tail call compatibility]
On Mon, 2014-12-29 at 13:02 -0800, Kevin Cantu wrote: It's easy to set up discuss to email you all the time, too: give it a try. That still loses you the thread structure of email discussion. I also can't start threads via the mail interface, and the mail interface regularly eats whole replies by people who are optimistic enough to to use it like nmatsakis. People can also edit their posts to append more information and I don't believe the mail interface would inform me of that. Also the settings page in Discourse invariably says We'll only email you if we haven't seen you in the last 10 minutes and you haven't read the thing we're emailing you about. which doesn't give me much confidence that I'm not somehow missing messages after following links on irc or wherever. It had gotten pretty clear that having a catch-all mailing list wasn't going to scale. It also doesn't scale for people to come to terms with a separate web based discussion forum for each project they keep up with or contribute to. Many projects use multiple mailing lists, it's not clear to me why that doesn't address the rust team's requirements. -ben Kevin On Dec 29, 2014 10:57 AM, Dmitry Romanov romano...@gmail.com wrote: I agree on almost every word. I have well sorted and with love configured mail, where I track several Libre projects. Now it is interesting to track rust questions. But dropping maillist most probably means I will not participate any more. I could add, as example, I have very limited Internet connection on cristmass trip now so the mail on my mobile is the only reliable way to track what is happening. Think about this reason too. On Dec 29, 2014 7:22 PM, Paul Nathan pnat...@alumni.uidaho.edu wrote: I have no desire to use Discourse, and nearly certainly won't sign up for it (I don't even understand why it came to be). I have never used Rust discourse besides happening once upon it and reading the linked thread. My membership in mailing lists is neatly sorted and segregated, easily readable on my mobile devices without extra signing up or poking at badly designed websites. Discourse gives me zero advantage for yet *another* website signup, and probably with less usability, given my experience of web site development design. It's worth noting that every single libre software project I have any interest in (from the arcane to the popular) maintains the mailing list as the primary official channel of communiques. If the Rust admins kill the mailing list, I will probably drop out of participation (what a loss. ;) ) and limit participation to lurking reddit's /r/rust (I don't contribute thoughtful stuff to reddit in part due to the fact that mobile website = awful, readers = ehhh and occasional IRC questions. I am sure I sound like a crabby crank, but, meh. On Sat, Dec 27, 2014 at 9:02 AM, Clark Gaebel cg.wowus...@gmail.com wrote: There was a thread about it on... Discourse! http://discuss.rust-lang.org/t/is-it-time-to-kill-the-mailing-list/611/36 On Sat, Dec 27, 2014 at 11:53 AM, Tomi Pieviläinen tomi.pievilai...@iki.fi wrote: The mailing list is mostly dead BTW. Consider bringing this up on discuss.rust-lang.org instead. This is the first time I've heard of that. I checked that it isn't even linked on the homepage, but the mailing list and IRC are. Have I missed something, or should the discourse then be linked instead of or at least in addition of the mailing list? -- Tomi Pieviläinen, +358 400 487 504
Re: [rust-dev] Confusing way to declare a uint
With the other numeric types, I'd assume. 0_i8, 0_f32 etc all work. On Mon, 2014-11-03 at 15:25 -0500, Evan G wrote: Not consistent with what? The syntax for number literals is taken directly from C/C++, and is used by many other languages. On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott jake@gmail.com wrote: I was trying to declare a uint using this: let a: uint = 0_uint; But the correct way to declare it is: let a: uint = 0u; Anyone else think that's not consistent? ___ 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 mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Met with a terrible fate
Hi! Anything in the std lib that touches the runtime (task spawning and concurrency stuff, i/o, probably `GcT` and some things I'm forgetting) will assert that it's being called from within a rust task, meaning it can obtain a reference to the runtime object providing those services from it. As far as I know, your options are pretty much to try really hard to avoid using that functionality in code called from C, or arrange for everything that makes use of the runtime into to be wrapped in a call to `native::start()` or `green::start()`, which start up and tear down a runtime object to make it available to user code they run. This isn't super satisfying so I hope someone proves me wrong and provides a better option. I vaguely hope that in the long run there'll be something you can call from all extern C functions like `start_up_a_runtime_in_the_background_for_this_thread_if_necessary()` that would make sure that subsequent code can use runtime services without requiring C code to be significantly restructured (and ideally also something more lightweight to catch task failure before it tries to unwind through C code), but afaik we aren't there yet. -benh On Thu, 2014-07-03 at 00:07 +0200, Isak Andersson wrote: Hello! I have written a library in Rust that has some pub extern fv's in it so that they are callable from C. I wrote a C program to try calling these functions and I was met with the following message: % ./test You've met with a terrible fate, haven't you? fatal runtime error: Could not unwind stack, error = 5 zsh: illegal hardware instruction ./test To begin with, nice reference! Second of all. How do I fix this, I am guessing that I need to start the rust runtime or something but I don't know how to do this, if someone could point me in the right direction that would be great! If you need more specific code examples of what I'm doing I can provide it it's just that I'm gonna sleep now and it doesn't seem like that's all too relevant. Also I did link to the libraries in the order it told me to. Cheers! Isak Andersson ___ 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] Syntax sugar: Vec Rc RefCell Box Foo - VecRcRefCellBoxFoo
I realize that, but simplifying ArcExclusiveVecBoxBufferT into Arc (Exclusive (Vec (Box (Buffer T wouldn't really buy us that much. On Sun, 2014-06-29 at 09:50 -0700, Cameron Zwarich wrote: This is pretty confusing to me because it’s associative in the opposite direction that function application is associative in functional languages with automatic currying. Cameron On Jun 28, 2014, at 3:48 PM, Benjamin Herr b...@0x539.de wrote: So, I've been vaguely concerned that types in a less sigil-heavy Rust inevitably devolve into what some call spikey lisp, and tried to come up with some more lightweight syntax. Of course, just removing syntax is the easiest way to make it weigh less, and it seems like the following doesn't actually break the grammar dramatically (only some macros!): In parsing a path, if a path segment is immediately followed by an identifier, start parsing another type right away and use it as the only element of the type parameter list for the current path segment. This is fairly limited: * It won't work for absolute paths as type parameters (since they'll look like just another path segment) * It also doesn't work for non-path types in type parameter lists * It doesn't simplify multiple type parameters I think that's okay, since it's a simplification that applies well to a lot of simple cases, and might still reduce the total depth of ``, `` nesting in more complicated cases. So, for example, the following desugarings would apply: Vec String = VecString Arc RWLock Vec f64 = ArcRWLockVecf64 Arc Exclusive Vec Box Buffer T = ArcExclusiveVecBoxBufferT // from libsync RefCell DefIdMap Rc Vec Rc TraitRef = RefCellDefIdMapRcVecRcTraitRef// from librustc HashMapVec String, Vec Rc Cell int = HashMapVecString, VecRcCellint AddComplex T, Complex T = AddComplexT, ComplexT std::mem::size_of RefCell String() // maybe a bit much? = std::mem::size_of::RefCellString()) I've patched that into libsyntax and `make check` passes... ... after changing some macros, since it basically means that adjacent identifiers parse as a single type (or expression, if we omit `::` too) and some macros try to match `($x:ty fake_keyword_ident ...)`, or have a case for `($x:expr)` and another for `(fake_keyword $x:expr)`, or just `($t:ty)*`. Seems like just chomping down on all adjacent identifiers makes the parser pretty aggressive... Yeah, okay, I don't know if this is really a good idea, and it's probably not RFC-worthy at this point, but imo it does make the syntax a bit easier on the eyes, and I think that's something we ought to look at at some point. ___ 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] Syntax sugar: Vec Rc RefCell Box Foo - VecRcRefCellBoxFoo
So, I've been vaguely concerned that types in a less sigil-heavy Rust inevitably devolve into what some call spikey lisp, and tried to come up with some more lightweight syntax. Of course, just removing syntax is the easiest way to make it weigh less, and it seems like the following doesn't actually break the grammar dramatically (only some macros!): In parsing a path, if a path segment is immediately followed by an identifier, start parsing another type right away and use it as the only element of the type parameter list for the current path segment. This is fairly limited: * It won't work for absolute paths as type parameters (since they'll look like just another path segment) * It also doesn't work for non-path types in type parameter lists * It doesn't simplify multiple type parameters I think that's okay, since it's a simplification that applies well to a lot of simple cases, and might still reduce the total depth of ``, `` nesting in more complicated cases. So, for example, the following desugarings would apply: Vec String = VecString Arc RWLock Vec f64 = ArcRWLockVecf64 Arc Exclusive Vec Box Buffer T = ArcExclusiveVecBoxBufferT // from libsync RefCell DefIdMap Rc Vec Rc TraitRef = RefCellDefIdMapRcVecRcTraitRef// from librustc HashMapVec String, Vec Rc Cell int = HashMapVecString, VecRcCellint AddComplex T, Complex T = AddComplexT, ComplexT std::mem::size_of RefCell String() // maybe a bit much? = std::mem::size_of::RefCellString()) I've patched that into libsyntax and `make check` passes... ... after changing some macros, since it basically means that adjacent identifiers parse as a single type (or expression, if we omit `::` too) and some macros try to match `($x:ty fake_keyword_ident ...)`, or have a case for `($x:expr)` and another for `(fake_keyword $x:expr)`, or just `($t:ty)*`. Seems like just chomping down on all adjacent identifiers makes the parser pretty aggressive... Yeah, okay, I don't know if this is really a good idea, and it's probably not RFC-worthy at this point, but imo it does make the syntax a bit easier on the eyes, and I think that's something we ought to look at at some point. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
On Sun, 2014-02-02 at 14:45 +1300, Nick Cameron wrote:
- The change adds boilerplate and nomenclature that is likely
unfamiliar to our target audience - 'for all' is well known to
functional programmers, but I believe that is not true for most users
of C++ (or Java). Being closer to the C++/Java syntax for generics is
probably more 'intuitive
So instead of 'for all', use 'template', and we're closer to C++ syntax
than ever!
templateT: typename, U: typename
struct Foo { ... }
templateT: typename, U: typename
impl TraitT for FooT, U { ... }
templateT: typename, U: typename
fn foo(...) { ... }
;-)
fwiw, like C++, Java generic methods also put the type parameter list
in front of the function signature rather than behind the function name:
public static T extends ComparableT
int countGreaterThan(T[] anArray, T elem) { ... }
... while C# apparently compromises and puts the type parameters between
the function name and value parameter list, but leaves the bounds for
later:
public static bool ContainsT(IEnumerableT collection, T item)
where T : IComparableT;
Neither approach translates too well into Rust, but that Rust is almost
the odd one out here makes me sympathetic to the desire to avoid
breaking up particularly function declarations between the name and the
value parameter list too much, in spite of the familiarity argument.
Of course, like everything else, that has to be balanced with avoiding
superficial but far-reaching overhauls of the language at the eleventh
hour. Alas!
-benh
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] do
On Sat, 2013-11-30 at 09:34 +0200, Oren Ben-Kiki wrote: This is a lose-lose situation. If the container takes a `proc`, then Rust complains that it can't capture the non-send-able variable. But if the container takes a stack closure, then Rust complains it can't use the owned variable. Of course, the container will _not_ send the action and will also _not_ call it twice, but it can't express this in the action type :-) The only workaround I found is to use a closure and wrap each and every non-send-able variable in a cell - this is an pointless and downright annoying manual boilerplate code. I think another previously mentioned workaround is to change all your closure-taking functions to have a name ending in _with and take an extra generic parameter by value that is then passed to the closure. In practice, that might end up being a tuple with all the values you're need to move into and from within the closure. It's not ideal and requires cooperation from the API but it probably reads better than a bunch of cells. :) -benh ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] freeing of locals
Hi, as I understand it, currently, rust zeros variables after cleanup or when moved from (and adds a drop flag field to structs with cleanup logic to be zeroed), and so dynamically, at runtime, tracks which variables need to be freed/have destructors called. This might change somewhat: https://github.com/mozilla/rust/issues/5016 -benh On Sat, 2013-11-16 at 17:59 +0100, spir wrote: Hello, say a function defines 4 pointed elements of data. Depending on logical conditions, one of them escapes the func to be assigned to some world variable (static or on heap), while another is returned. How does Rust determine which of those data are to be freed? Seems this can only be done dynamically, at runtime, or do I miss a relevant point? Is there a cheap algo to do this? (Also, those elements of data can be arbitrarily complex, and hold other pointed data which themselves may be placed there conditionally.) Thank you, denis ___ 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] Some suggestions of Rust language
On Wed, 2013-09-25 at 14:29 -0400, Benjamin Striegel wrote:
Is there a use case that necessitates such a feature? The following
code works today:
let a = 1;
let b = 2;
let (a, b) = (b, a);
Not sure why that wouldn't be sufficient.
Motivating toy example then ;)
fn fib() {
let mut a = 0;
let mut b = 1;
loop {
printfln!(a);
(a, b) = (b, a + b);
}
}
(I miss `let mut (a, b) = ...`!)
-benh
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Some suggestions of Rust language
On Wed, 2013-09-25 at 15:23 -0600, Jack Moffitt wrote: (I miss `let mut (a, b) = ...`!) Miss it? Did it ever work? This seems like a bug though. Mutability is inherited, so without this there's no way to do mutable destructuring bind right? jack. Apparently it went away in commit f9b54541 and the workaround used there is `let (foo, bar) = ...; let mut foo = foo;` etc. Seems intentional, but I don't recall the rationale. -benh ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Owned pointers vs raw pointers (newbie question)
On Sat, 2013-05-25 at 11:09 +0100, Thomas Leonard wrote:
Hi,
Hi!
I'm trying to interface to some C code which uses a lot of structs. I
can declare these using raw pointers, but then I lose the benefits of
Rust's compile-time pointer checking. So I tried replacing the raw
pointers with owned pointers, which more accurately captures the
meaning of the C interface. But when I do this, the pointers get
offset by 32 bytes.
[...]
Yeah, there's currently some overhead for owned boxes. From what I
understand, they share the structure of the refcounted managed boxes
with most of the fields nulled out (there's a struct to that effect in
https://github.com/mozilla/rust/blob/incoming/src/libstd/managed.rs#L17
I believe).
I figure this is because managed boxes were there first, and owned boxes
kind of grew out of them, and this is going to change eventually when
someone gets around to it...
For example, I'd like to replace this:
struct xmlNode {
name: *i8,
...
}
with:
struct CString;
struct xmlNode {
name: ~CString,
...
}
Then I could (I assume) define safe functions on my CString type (len,
eq, etc) and not have to worry about memory leaks, etc when using them
from safe code.
Is this possible?
I don't believe this is possible in general even accounting for the box
headers somehow because rust isn't promising what malloc/free
implementation it is using for owned pointers.
Maybe someone else has a better idea, but you could wrap the unsafe
pointer into a struct with a safe interface and an impl for the Drop
trait that calls libc's free() for much the same semantics, if a bit
more awkward syntax. I think a type like this ought to be in libextra at
some point, but I don't think there is yet.
https://github.com/mozilla/rust/blob/incoming/src/libextra/rc.rs does
something similar with refcounting instead of unique ownership
semantics, maybe that's a starting point.
Good luck,
Benjamin Herr
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
