Re: [rust-dev] C++ to Rust - Is that about right?
On 2014-07-15, at 13:51 , Steve Klabnik st...@steveklabnik.com wrote: let z = box(std::gc::Gc) Point::good_new(); // this is a GcPoint, with no copy. } Unless that's changed in 0.11, IIRC that should be box(std::gc::GC). Which remains weird and annoying, is there any plan to drop the static and allow the type there when/once boxes become pluggable? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Integer overflow, round -2147483648
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote: On 22/06/14 05:09 PM, Rick Richardson wrote: Apologies if this has been suggested, but would it be possible to have a compiler switch that can add runtime checks and abort on overflow/underflow/carry for debugging purposes, but the default behavior is no check? IMO this would be the best of both worlds, because I would assume that one would really only care about checked math during testing and dev. You would need to build an entirely separate set of standard libraries with checked overflow. From my understanding, everything would be built with checked overflow (unless explicitly disabled/bypassed), and the overflow check could be disabled at compile-time/. I don't think that's a good solution, but that's what Swift's `-Ofast` does, it completely removes a number of checks (including overflow checking), essentially making the language unsafe but much faster. As a side-question, were the performances of ftrapv (in clang) ever actually tested? There were some discussion on testing the impact in Firefox, but that ended up with GCC's ftrapv being broken and not doing anything, and Firefox not working with clang -ftrapv. I've not seen any numbers since, just lots of assertions that it's far too slow to be an option. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to find Unicode string length in rustlang
On 2014-05-29, at 08:37 , Aravinda VK hallimanearav...@gmail.com wrote: I think returning length of string in bytes is just fine. Since I didn't know about the availability of char_len in rust caused this confusion. python 2.7 - Returns length of string in bytes, Python 3 returns number of codepoints. Nope, depends on the string type *and* on compilation options. * Python 2's `str` and Python 3's `bytes` are byte sequences, their len() returns their byte counts. * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code units count which may be UCS2 or UCS4 (depending whether the interpreter was compiled with `—enable-unicode=ucs2` — the default — or `—enable-unicode=ucs4`. Only the latter case is a true code points count. * Python 3.3's `str` switched to the Flexible String Representation, the build-time option disappeared and len() always returns the number of codepoints. Note that in no case to len() operations take normalisation or visual composition in account. JS returns number of codepoints. JS returns the number of UCS2 code units, which is twice the number of code points for those in astral planes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to find Unicode string length in rustlang
On 2014-05-28, at 11:10 , Aravinda VK hallimanearav...@gmail.com wrote:
Hi,
How to find number of characters in a string?
Problem 1: define character. Do you mean a glyph? A grapheme cluster? A
code point? Composed or decomposed?
Problem 2: what use is knowing the length of a string?
.len() returns the length of the string in bytes (using its underlying
UTF-8 representation), .char_len() returns the number of non-normalized
code points. AFAIK there is no way to know the number of grapheme
clusters (I don't think there is a Rust implementation of UAX #29) and
glyphs make no sense for text which is not rendered.
Following example returns byte count instead of number of characters.
use std::string::String;
fn main() {
let unicode_str = String::from_str(ಅ);
let ascii_str = String::from_str(a);
println!(unicode str: {}, ascii str: {}, unicode_str.len(),
ascii_str.len());
}
--
Regards
Aravinda | ಅರವಿಂದ
http://aravindavk.in
___
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] Language to replace C
On 2014-03-04, at 21:37 , John Mija jon...@proinbox.com wrote: El 04/03/14 20:24, Daniel Micay escribió: On 04/03/14 02:43 PM, John Mija wrote: So, why don't use a simple language but safe like Go? Go isn't safe. It has data races. True, but Go includes a built-in data race detector: http://golang.org/doc/articles/race_detector.html Which can only discover a limited subset — even if significant — of all possible data races. It does not and can not eliminate data races, only make them less likely. Anyway, this problem will be solved when the compiler and linker been build in Go, instead of C. Shared-memory concurrency is the source of data races *and* a core semantic of Go. Why would a rewriting of the toolchain fix an intrinsic consequence of the language's memory model? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Configuration files library for Rust
On 2014-01-04, at 21:45 , Patrick Walton pwal...@mozilla.com wrote: I would love to have a TOML parser. I've always had a bit of a fondness for the INI format, despite its limitations, and TOML looks like the best of both worlds (the expressivity of JSON and the simplicity and readability of INI). Well IIRC ini is undefined and basically a wild west aside from having bracket-enclosed section names. So for all intents and purposes TOML is a strict and well-defined ini dialect (compared to most ini dialects anyway). In fact I believe its original tagline was TOML is like INI, only better. Benchmarks of TOML parsing would be fun too :) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Interface around SQL databases
On 2013-12-11, at 15:24 , Gaetan gae...@xeberon.net wrote: I'll be glad volunteering for this task, however I'm new in rust so I may need to have some mentoring for this... I would be inspired by the python interface: https://pypi.python.org/pypi/MySQL-python/1.2.4 A better inspiration than a specific module would probably be PEP 249 “DBAPI 2”[0], or Perl’s DBI[1]. [0] http://www.python.org/dev/peps/pep-0249/ [1] http://dbi.perl.org/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] A la python array access
On 2013-11-20, at 11:16 , Gaetan gae...@xeberon.net wrote: actually that was what I was expected, sorry I'm not very confortable with slices yet. It should not allocate, indeed, there is no reason. Python doesn’t allocate but the way it handle items, it doesn’t really behave like rust's slices Slicing a list in Python will allocate and return a new list[0] It does not have to, and you can easily implement a sequence type which will return a genuine slice object (aka a triple of the parent object, an offset and a length), but that’s not what list does. I believe memory views[1] slicing behaves the way lower-level languages expect. So do numpy arrays. [0] http://hg.python.org/cpython/file/adb471b9cba1/Objects/listobject.c#l431 [1] http://docs.python.org/2/library/stdtypes.html#memoryview-type ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Go 1.1 Function Calls
On 2013-10-02, at 08:51 , Corey Richardson wrote: Saw this on HN: https://docs.google.com/a/octayn.net/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub I haven't been following the recent closure discussions much, but what Go is doing might be relevant? FWIW, various commenters have noted that this looks like standard closure conversion, which I would expect Rust's team to already be aware of. The only interesting parts would be go's implementation details, and I'm not sure they're of much relevance to Rust. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Some suggestions of Rust language
On 2013-09-25, at 17:29 , Patrick Walton wrote:
Multiple return values
if has a function like this:
fn addsub(x : int, y : int) - (int, int) {
return (x+y,x-y);
}
them, this is valid:
let (b,c) = addsub(x, y);
but this is invalid;
let b:int =0;
let c:int =0;
(b,c) = addsub(x, y);
also invalid:
let (b,c) = (0, 0);
(b,c) = addsub(x, y);
If we did this, we wouldn't know whether to parse a pattern or an
expression when starting a statement. This isn't fixable without trying
to define some sort of cover grammar that covers both expressions and
patterns, like ECMAScript 6 does. I don't know if this would work in
Rust.
There seems to be a bug somewhere though, ignoring that the bindings are
not mut in the example (making them immutable unless that's changed
recently) the compiler freaks out quite a bit:
test.rs:8:4: 8:10 error: internal compiler error: trans_lvalue reached
fall-through case: expr_tup(~[@{id: 38, node: expr_path(@{span: {lo:
{__field__: 121}, hi: {__field__: 122}, expn_info: None}, global: false,
idents: ~[{name: 70, ctxt: 0}], rp: None, types: ~[]}), span: {lo:
{__field__: 121}, hi: {__field__: 122}, expn_info: None}}, @{id: 39,
node: expr_path(@{span: {lo: {__field__: 124}, hi: {__field__: 125},
expn_info: None}, global: false, idents: ~[{name: 71, ctxt: 0}], rp:
None, types: ~[]}), span: {lo: {__field__: 124}, hi: {__field__: 125},
expn_info: None}}])
test.rs:8 (b, c) = addsub(1, 2);
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
On 2013-09-19, at 23:45 , Kevin Ballard wrote: Yes I know, but in my (rather limited) experience with Python, triple-quoted strings are typically used for docstrings. It was just an example anyway. They're also commonly used for multiline strings as single-quoted strings don't require it. * The quote-escaping oddness is less of an issue in Python as you can also use single-quotes for delimiting, or use triple-quoted strings (if you need to embed both single and double quotes in rawstrings). If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. Also, windows file paths windows paths can also use forward slashes so that's not a very interesting justification. Not always. UNC paths must start with \\ (in my testing, //foo/bar/baz is not interpreted as a UNC path by the Windows File Explorer, but \\foo/bar/baz is). True. Do you expect writing literal UNC paths in Rust to be a common occurrence? There's also paths that start with the verbatim prefix \\?\, which disables interpretation of forward-slashes (among other things). That's not really relevant to a rawstrings proposal, why would a developer embed such a path literally? As I am actively engaged in writing a replacement for the path module, and am currently expanding the test suite for Windows paths, raw strings would be extremely useful to me. I'd have thought it a better idea to use path builders (maybe macros) and avoid embedding literal path separators in order to avoid portability issues. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
On 2013-09-20, at 10:26 , Marijn Haverbeke wrote: If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. You should note that, as soon as you include something in the language itself, that creates meaningful strings (programs in the language) that include the token, which are not likely, at some point, to need to be written as a multiline string in the language itself. It's already noted, my objections are very much that this is highly unlikely to be an issue as it only comes to a head when needing *triple-quoted rawstrings* to include *their own* delimiters (meaning a triple-quoted rawstring which needs to include both triple-quoted delimiters at the same time). Even unlikelier given python will concatenate string literals during parsing. On 2013-09-20, at 10:25 , Kevin Ballard wrote: Regular expressions is really the most common application here. Right, which was just about all I was saying in the original message. People still use literal path separators in strings all the time in languages that support path-building methods. Something I don't believe should be encouraged. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
On 2013-09-19, at 22:36 , Kevin Ballard wrote: I welcome any comments, criticisms, or suggestions. * C# also has rawstrings, which were not looked at. C#'s rawstrings disable escaping entirely but add a new one: doubling quotes will insert a single quote in the resulting string (similar to quote-escaping in SQL or Smalltalk). * The docstring comment is incorrect, a docstring is a string in the first position of a module, a class statement or a function statement. A single-quoted string at these positions will yield a docstring. The triple-quoting is a string syntax embedding newlines (single-quoted strings can not contain literal newlines in Python, only escaped ones). Obviously, triple-quoted python string can be raw. * The quote-escaping oddness is less of an issue in Python as you can also use single-quotes for delimiting, or use triple-quoted strings (if you need to embed both single and double quotes in rawstrings). * Perl's quotes and quote-like operators would certainly deserve mention. Also, windows file paths windows paths can also use forward slashes so that's not a very interesting justification. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Augmented assignment
On 23 août 2013, at 12:44, Chris Morgan m...@chrismorgan.info wrote: https://github.com/mozilla/rust/issues/5992 (Coming from a Python background I know the concept as augmented assignment; they are also known as assignment operators. Or just +=, ^=, = and the like.) I want augmented assignment in Rust for all types, so I had a crack at implementing this. I have an implementation mostly complete in my augmented-assignment branch (https://github.com/chris-morgan/rust/compare/augmented-assignment), but even if I managed to convince the Rust side of rustc that I was competent, LLVM called my bluff. The last state of my branch and what appears to be wrong (extra argument going to the LLVM Call) is documented in #5992. Is there anyone who would be able to look at my patch and get it to work (or even figure out just where the wrong is)? I just rebased it and so it is up to date, but if left for another few weeks it doubtless will continue to bitrot. For the record, I think augmented assignments are a terrible ideas and one of the worst features of python. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] HTML5 parser
On 2013-08-14, at 10:15 , Archos wrote: But now, Google has opened-sources Gumbo, a C Library for Parsing HTML5. So it could be used until that somebody builds a parser in pure Rust. https://github.com/google/gumbo-parser That’s cool, but what would it buy us to switch from one C library to another? Is Gumbo better than Hubbub? Well, it has tested on over 2.5 billion pages from Google's index. Only to ensure that it doesn't crash as far as I can see. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Redesigning fmt!
On 2013-07-29, at 11:04 , Huon Wilson wrote: On 29/07/13 18:26, Masklinn wrote: I don't have much to say, but On 2013-07-29, at 06:24 , Alex Crichton wrote: * Any argument can be selected (0-indexed from the start) keyword/named selection is *really* great for longer/more busy patterns, it makes format string much more readable both in-code and for translators (who usually lack part of the context, even with comments, especially if they are non-technical). I think this is one of the great strengths of Python's string formatting (both C-style and C#-style) or Ruby's string interpolation, and if the formatting language is going to be reworked away from C-style formats it would be nice to include it if possible. I don't think it can be integrated directly into the current grammar though, as there'd be ambiguity with the function spec. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev fmt! is a syntax extension (which receive their arguments as tokens, not at all parsed), so it can actually define its own syntax for named arguments, without any modifications to Rust's grammar (as long as it tokenises) I was talking about the fmt! syntax described by Alex here, not Rust's grammar. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc rewrite and redesign
On 2013-06-20, at 00:11 , Corey Richardson wrote: On Wed, Jun 19, 2013 at 4:32 PM, Masklinn maskl...@masklinn.net wrote: On 2013-06-19, at 22:01 , Corey Richardson wrote: I am going to rewrite and redesign rustdoc. Current bikeshed: https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc Please discuss, give me your feature requests, comments, etc. This is just the data extraction from rust source, then a separate-ish TBD backend would turn it into markup for either use or further processing (e.g. a markdown/pandoc generator for the current one, some sort of autorustdoc for sphinx integration, …) correct? No. It is all a part of rustdoc, it's just a more modular design. Then I'd wish for the option to just get a raw-ish stream of language-independent data events (think TAP). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc rewrite and redesign
On 2013-06-21, at 03:02 , Brian Anderson wrote: On 06/20/2013 04:44 PM, Daniel Micay wrote: On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson bander...@mozilla.com wrote: Regarding HTML generation, I think we should not lean on pandoc so heavily. rustdoc currently produces a page of markdown at a time to pass to pandoc. This conversion drops a lot of semantic content on the floor. We should instead output proper semantic HTML that is tailored to Rust and only use a markdown renderer to convert small sections of doc comments to HTML. We could be making much better use of pandoc since it uses a superset of markdown. For example, with an up-to-date pandoc, the function signatures and code examples get syntax highlighted. http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown Another thing to consider is switching to sphinx and avoiding the pain of doing this all ourselves. Converting our markdown to restructured text would be pretty trivial. I guess if we're going to switch to sphinx now is the time, but I haven't looked at it. Their web page does make it sound fairly python-centric though. It was created for Python and is developed in Python (so is the underlying docutils library for processing restructuredtext), so the main community using it is the Python community, but sphinx isn't python specific at all. Most of the markup is generic text things, it bundles non-python domains[0] (code coloration uses pygments so it already does way more than just python) and there is an API for creating new domains, you can find examples of such new domains as part of sphinx-contrib[1]. Switching rust's documentation to sphinx would likely require developing a Rust domain so Sphinx can create all the right cross-references, e.g. :func:`str::each` linking to the right place without requiring further efforts by the documentation author. [0] http://sphinx-doc.org/latest/domains.html#the-c-domain [1] https://bitbucket.org/birkenfeld/sphinx-contrib/src ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] A case for removing rusti
On 2013-05-29, at 07:17 , Alex Crichton wrote: In my opinion, rusti gets the job done. Yes, having in-memory compiled state would work a lot better. But I don't know how viable that is. I know for a fact that a big feature plan is to have the compiler only partially compile when applicable, i.e. only compile things are actually important. That would help drastically here. For me, if I use rusti I expect to get all of rust and everything that entails. Although I don't think rusti works well enough now (I don't think many would disagree), I think this expectation is essentially crazy, Rust not being a language where everything happens at runtime, it seems only logical that there will be limitations on what an interpreter can do, just as there are limitations on what ghci[0] does compared to ghc, or the erlang shell compared to an actual erlang module[1]. That said, I'd also expect additional features (not available in a normal program) for observing and investigating the current available environment as Rust doesn't (as far as I know) provide these in the core language/library (for obvious reasons already mentioned): where one can use standard ruby or python objects and methods to introspect the interpreter's namespace[2], ghci has to provide a number of dedicated command[5] to introspect the interpreter's state and interact with the external environment sensibly. [0] Talking about ghci, how does it work? Haskell is also a compile-heavy language but ghci has very little issues, could rusti work the same way? [1] Part of these limitations stem from eshell being a console, a shell, an interface for interacting with a running erlang node before being a REPL. Which makes me wonder if Rust will provide a basis for such things, providing arguments to the runtime itself à la GHC[3] and allowing external tools to connect to a running Rust program and inspect/interact with it à la Erlang[4]? [2] And even then, augmented REPLs such as ipython or bpython have added REPL commands separate from Python's own. [3] http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/runtime-control.html#rts-opts-cmdline [4] http://www.erlang.org/doc/apps/webtool/webtool_chapter.html http://www.erlang.org/doc/apps/appmon/appmon_chapter.html http://www.erlang.org/doc/apps/observer/observer_ug.html http://www.metabrew.com/article/bigwig-erlang-webtool-spawnfest [5] http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/ghci-commands.html ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Do-notation?
On 2013-05-23, at 14:28 , Benjamin Striegel wrote:
There's no generalized notation, but a while ago I overloaded the +
operator on Option such that it automatically unwraps them, adds the
contained elements together (for any two types that implement Add), and
returns a wrapped result.
let foo = Some(1) + Some(4);
error!(foo); // Some(5)
This behavior seems mostly innocuous, but there's some question as to
whether the behavior is correct (and also whether we want to support this
sort of overloading at all): https://github.com/mozilla/rust/issues/6002
If this sort of thing is useful, it's feasible that we could overload the
other operators as well.
I think that's way too specialized and repetitive for the general case.
A form of zip/map_zip for option would be better as it'd allow applying
arbitrary operations cleanly, something along the lines of fn zipT,
U(t: OptionT, u: OptionU) - Option(T, U)
And thus you would write something along the lines of:
let foo = option::zip(Some(1), Some(2)).map(|(a, b)| { a + b })
zip would be something along the lines of:
match (t, u) {
(Some t1, Some v1) = Some (t1, v1),
_ = None
}
(well it would require pointer and lifetime powder thing, but you get the idea)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Documentation, completeness cross-reference hyperlinks?
On 2013-05-20, at 07:52 , Jeaye wrote: On 05/19/2013 02:09 PM, Lucian Branescu wrote: I don't see it either, fwiw. Ok, so I'm not crazy. I was wondering the exact same thing. Can we get the original message sent to the list, Masklinn? It has been but it's apparently got caught in some sort of filter I assumed a list admin would let it go through, either none's been online or I assumed wrong. Let me try again. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Documentation, completeness cross-reference hyperlinks?
On 2013-05-20, at 07:52 , Jeaye wrote:
On 05/19/2013 02:09 PM, Lucian Branescu wrote:
I don't see it either, fwiw.
Ok, so I'm not crazy. I was wondering the exact same thing. Can we get the
original message sent to the list, Masklinn?
Yesterday as I was trying to provide more info/background for an
answer to the list, I encountered an issue which I think is going
to hinder lots of people trying out rust: using the documentation
is an exercise in frustration.
To expand, I hit 2 main pain points:
1. I wanted to see all the built-in ways to use OptionT (aside
from simply pattern-matching on None and Some), for this I
went to the corresponding doc page
http://static.rust-lang.org/doc/0.6/core/option.html. Although
probably not the worst by a long shot, this page still
demonstrates a number of issues:
- None of the methods provides examples showing off their
purpose and how they can improve code. For some of them, it
makes understanding their power and purpose much harder
(e.g. Option.each) especially for people coming from languages
without these facilities and thus not actively looking for them
- The only examples could actually be simpler if replaced by
using one of Option's methods, e.g. I believe the second
example
let unwrapped_msg = match msg {
Some(m) = m,
None = ~default message
};
could have been written:
let unwrapped_msg = msg.get_or_default(~default message);
and would demonstrate the value of the corresponding method
(this could of also be used as a teaching device by first
showing raw examples then showing how the code can be
simplified/improved using the module's toolbox, but it's not
the case here)
(and the example is incorrect in the first place, the
compiler rejects `Some(ref m) = io::println(m)`, this
should be `Some(ref m) = io::println(*m)`)
- The uniform color scheme, font and indentation make it hard
to notice e.g. admonitions (several methods will fail on a
None, have a note indicating it, but the node melds into the
rest of the document)
- None of the method is hyperlinked from the module's top (or
some sort of sidebar) and it's impossible to get a link to
them short of inspecting the page's HTML source
Now part of these issues are tooling and parts are
copywriting, most are easily fixable per-documentation the
issue is that they're exist across all of the
documentation. But there's a bigger issue:
2. Missing cross-section hyperlinks and references. There I was
looking for the various formats available in fmt!. fmt! is
mentioned and used extensively in the Rust tutorial[0] and is
also listed as an example macro in the reference manual[1].
Yet *not one* of the mentions is hyperlinked to any
specification or documentation for it.
The core library[2] nor the standard library[3] indexes don't
list anything having to do with fmt! either.
And to add insult to injury, the first mention of fmt! in the
tutorial is linked to the documentation for C++'s printf[4]
but *not* to any fmt! related documentation.
I ended up finding extfmt[5] (after quite a bit of googling),
but looking for it wasn't exactly fun.
As I mentioned part of it is basic copywriting (and putting the
effort in), but I think part of it is also tooling: nobody is
going to bother looking up the exact url to the
spec/documentation of fmt! (if it even exists, does it?).
Having short syntaxes for object-aware hyperlinks (e.g. being
able to easily link to the definition/documentation of a macro,
module, function, type or method) in the way of Sphinx domains[6]
and extensively using these would solve the issue at least in
part, but I don't know if Pandoc can be extended in such a way,
or if the Rust team would be willing to switch to Sphinx[8].
[0] http://static.rust-lang.org/doc/tutorial.html
[1] http://static.rust-lang.org/doc/rust.html#syntax-extensions
[2] http://static.rust-lang.org/doc/core/index.html
[3] http://static.rust-lang.org/doc/std/index.html
[4] http://static.rust-lang.org/doc/tutorial.html#syntax-extensions
[5] http://static.rust-lang.org/doc/core/extfmt.html
[6] http://sphinx-doc.org/latest/domains.html there is no Rust domain
at the moment, but a custom one can be written[7]
[7] http://sphinx-doc.org/latest/ext/appapi.html#domain-api
https://bitbucket.org/birkenfeld/sphinx-contrib
[8] that would give the documentation code-coloration for free as well,
since there is already a Rust lexer in Pygments:
http://pygments.org/demo/81135/, though of course Rust support
can also be added to Pandoc.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Documentation, completeness cross-reference hyperlinks?
On 2013-05-19, at 15:59 , Masklinn wrote: [8] that would give the documentation code-coloration for free as well, since there is already a Rust lexer in Pygments: http://pygments.org/demo/81135/, though of course Rust support can also be added to Pandoc. And apparently it's already been added[0] but is not on the bots yet, I should have checked harder. Sorry about that one. [0] https://github.com/mozilla/rust/issues/5259 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Having zip() fail when the two iterators are not the same length
On 2013-05-05, at 22:19 , Noam Yorav-Raphael wrote: Hello, My name is Noam Yorav-Raphael. I find Rust to be a really exciting language! I have a simple suggestion: the current implementation of zip() returns an iterator which stops whenever one of the two iterators it gets stop. I use zip() in python quite a bit. I always have a few lists, where the i'th value in each corresponds to the same thing. I use zip in python to iterate over a few of those lists in parallel. I think this is the usual use case. In this use case, when the two lists have a different length it means that I have a bug. it seems to me that Python's behavior, and current Rust behavior, is contrary to Errors should never pass silently from the zen of Python. What do you think of changing this, so that zip() will fail in such a case? Another iterator, say, zipcut can implement the current behavior if needed. It will be my pleasure to implement this, if the suggestion is found useful. FWIW there are languages falling either way, Haskell's zip is shortest: Prelude zip [1..3] [1..4] [(1,1),(2,2),(3,3)] Prelude zip [1..5] [1..4] [(1,1),(2,2),(3,3),(4,4)] while erlang's is strict: 1 lists:zip([1, 2, 3], [1, 2]). ** exception error: no function clause matching lists:zip([3],[]) (lists.erl, line 372) in function lists:zip/2 (lists.erl, line 372) in call from lists:zip/2 (lists.erl, line 372) 2 lists:zip([1, 2, 3], [1, 2, 3, 4]). ** exception error: no function clause matching lists:zip([],[4]) (lists.erl, line 372) in function lists:zip/2 (lists.erl, line 372) in call from lists:zip/2 (lists.erl, line 372) I've never had issues one way or an other, but note one thing: zip shortest is the most useful one when the language has infinite sequences (infinite lazy lists in Haskell, infinite generators/iterators in Python) as it allows zipping an infinite and a finite and get a sensible (and terminating) result, e.g. zip(itertools.count(), collection) thus it is not an error to do it that way but an extremely useful property. Because Erlang's lists are strict and finite, an assertion of equal length makes sense: there are no infinite streams to zip to, zipping of lists of different length can pretty much only be a bug. Now here's the question, to which I don't have an answer but which will tell you whether your suggestion makes sense — at least when compared to existing languages: is it possible to have an infinite vector in Rust, or to zip finite and infinite datastructures (iterators?) together? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Having zip() fail when the two iterators are not the same length
On 5 mai 2013, at 22:51, Daniel Micay danielmi...@gmail.com wrote: On Sun, May 5, 2013 at 4:49 PM, Masklinn maskl...@masklinn.net wrote: Now here's the question, to which I don't have an answer but which will tell you whether your suggestion makes sense ― at least when compared to existing languages: is it possible to have an infinite vector in Rust, or to zip finite and infinite datastructures (iterators?) together? Yes, you can make infinite generators implementing the Iterator trait. One example of that is `iterator::Counter::new(1, 2)` which is the same as `[1,3..]` in Haskell. I know you can create infinite iterators but can you *zip* to one was the question. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Having zip() fail when the two iterators are not the same length
On 5 mai 2013, at 23:00, Noam Yorav-Raphael noamr...@gmail.com wrote: Indeed you can. But do you think of a useful, common use case? I think it's a useful feature. Common is not really relevant and will depend on your coding style. Starting to count from 0 is indeed very useful, but you can use enumerate() for this. It was an example. It seems to me that in the rare cases where it's useful, a special version like zipcut should be used, so that the usual use case will be checked for errors. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] I want to write more docs
On 2013-04-05, at 23:01 , Valentin Gosu wrote: On 5 April 2013 22:51, Steve Klabnik st...@steveklabnik.com wrote: More on the ffi docs that specifically shows callback examples would be useful. I think working examples for every function and structure described in the docs would be great for newbies. The server-client example I built 2 weeks ago isn't working any more, so it would be great to rebuild it with working snippets. For that, a gofix-type tool might be nice: although the dev team would like the language to be frozen, details may still change as needed and having a tool able to migrate Rust 0.6 code to 0.7 and 0.8 and… transparently would be neat. Event more so if it prints the changelog notes for the stuff it fixes, so the developer can learn what changed of what he knew/used. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] I want to write more docs
On 2013-04-05, at 23:35 , Brian Anderson wrote: On 04/05/2013 02:32 PM, Jack Moffitt wrote: rustfix is high on everybody's list of things we would like to have. it's a sizeable and difficult project though. Since I don't think something that could have ported servo is likely to ever exist, perhaps a good first milestone is just something that can make the easy changes like removing `pub` from `pub impl X for Y` and s/const/static/. It seems like it needs a minimal amount of syntax awareness and would at least automate the main drudgery. Is the rust parser exposed as a library? jack. The rust parser is available as a library, yes. And does Rust support loading/using multiple versions of the same library? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Announce: rustle, an api search tool
On 2012-10-19, at 03:05 , Daniel Patterson wrote: I'm announcing an initial version of an API search tool for Rust called Rustle. It is inspired by the api search tool for Haskell called Hoogle (http://www.haskell.org/hoogle). Haskell's community also has Hayoo[0], which is less focused on type-searches (though they still work well), and has quite a few interesting feature (e.g. the type cloud which displays type-searches similar to the one entered). It's also based on an indexing library which could be imitated to provide generic API searching capabilities to Rust. [0] http://holumbus.fh-wedel.de ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why does Rust compile slowly?
On 2012-10-14, at 19:48 , Yiannis Tsiouris wrote: Hi, The build includes not only all of LLVM, but Clang as well. Sorry if this is something obvious, but why is clang *needed* for Rust? Without looking into the makefiles (so this really is nothing more than a guess): rust calls llvm's makefiles, which default to building clang as well, and nobody's been bothered enough to check which options should be passed to llvm's makefile to make it not build clang? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why does Rust compile slowly?
On 2012-10-14, at 21:16 , Patrick Walton wrote: * Rust builds itself three times for bootstrapping. This is unavoidable as long as Rust is bootstrapped. Aren't the second and third builds for sanity-checking purpose? Surely if (when) Rust is mature and distributed as a tarball for source-based systems, only stage1 compile will actually be needed? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Class UI
I was reading http://smallcultfollowing.com/babysteps/blog/2012/04/09/rusts-object-system/ today, and saw the description of the classes definition. Next to it, Nicholas notes: I am not fond of the definition of constructors, in particular I can only agree, for a simple reason: the example is that of an initializer, but uses naming generally used for actual constructors. Let's back up to what I mean: the role of a constructor is to construct, so it would take nothing, allocate a chunk of memory and put object content in it, then return the type-tagged chunk of memory (or a reference to it with runtime/GC cooperation). An initializer is the part the constructor delegates to for the put object content in it, all arguments to the constructor are forwarded to the initializer but the initializer gets a ready to use object and makes it readier by initializing fields if needs be. I realize some languages (mostly in the Java line) call the initializer constructor and give no access to the constructor itself, that's fine. There's also C++ which gives access to both as respectively the constructor and *the new operator*. The latter part hints at what bothers me with the current syntax/naming: languages giving access to actual constructors (the class method which handles allocation and fully creates an instances from scratch) very often use the `new` naming: C++ uses `operator new` (called through the likewise named operator), Python uses `__new__` (called through the call operator `()`), Ruby uses `new` (called directly on the class), and I think that's how Perl5 seems to work (the instance is created within a proc called `new` — from scratch — then blessed and returned). The only significant differer I've found seems to be F#. As a result, really don't think Rust should call its initializer `new`. Although I *do* think it would be neat if Rust provided an actual constructor which would have to return some sort of instance build from scratch using core memory allocation thingies. But whether it provides a constructor or not, it should not name its initializer `new`. `init` is sometimes used, at least in javascript class libraries as well as in Objective-C[0] (and in Python, with dunders since it's a magic method) (Ruby uses `initialize`) [0] Yeah I know it's a bit weirder in Obj-C as it can return the instance as well, but the memory for the instance is setup in a preceding `alloc` call so it still works. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] hashmap benchmark
On 2012-04-08, at 23:21 , Niko Matsakis wrote: On 4/8/12 12:15 PM, Stefan Plantikow wrote: Hi, I was thinking about this, too. One of the state-of-the art algorithms seems to be hopscotch hashing, wikipedia has a quite good introduction to it. Even though it has been developed for concurrent access, it should also be quite good in a single core scenario and has a really low memory footprint (90% full hash table still works reasonably). I was thinking about implementing that for fun once the currently ongoing changes to regions and vectors are complete. I am totally excited about offering a variety of map abstractions. One additional thing I would particularly like (which is kind of orthogonal) is a default map implementation that begins as a straight-up list of some fixed size and then shifts to another algorithm as the table is populated. Of course we'd want to test and tune to see where it makes sense to shift, but I believe that a lot of hash tables are generally small (but not always) and thus can benefit from changing strategies as they fill up. In fact I would like to have a similar approach to each of the basic container types (a default implementation that adjusts and does the right thing, plus a variety of more specific implementations). Cocoa has a lot of that kind of things, if somebody wants to do it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Confusion with regard to error handling
On 2012-03-19, at 18:28 , Graydon Hoare wrote: The longer answer is that we're familiar with the CL condition system as well as a number of alternatives, and need to spend some time exploring to find what fits the Rust semantics best. I spent quite a while sketching, prototyping and researching this aspect of the language before getting started, and wound up adopting a wait and see approach, letting other language features mature first. It's a complicated topic and there's a lot to say. To summarize where my thinking on it is _now_, it's something like so: - The CL system is overengineered (separated handle vs. restart) What about Smalltalk? It also has conditions (in that the stack is *not* unwound before the handler is executed and execution can be resumed) but does not have all the formal complexity of CL's restarts. Instead, the error handler can just send `resume` or `resume:` to the error object, and execution will resume from the point having thrown the error, returning the value if any is provided[0]. Smalltalk provides/d a few other neat handling strategies (most being linked to Smalltalk's error handling being bound to a block): * `retry` would re-execute the block * `return` `return:` would just return (from the block) * `retryUsing:` would replace the original block with the one provided and then execute *that* (with the error handler rebound there) * `pass` would just let the exception bubble up * `outer` would behave like `pass` but wrap the exception: in case of `resume` (in an outer handler) execution would resume from this handler instead of the original creator of the exception [0] there's a small caveat in that the exception needs to be resumable — answer `true` to the message `isResumable` ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] First thoughts on Rust
On 2012-01-23, at 05:37 , Kevin Cantu wrote: I'm curious though, because I've not used it in depth, what makes NSString so good. What does it do that Haskell's Text and other languages' string types don't do? First-class interaction with grapheme clusters (which it calls composed characters)[0], I don't remember seeing that in any other language, and good first-class (not tucked in a library hidden out of the way) support for Unicode text manipulation algorithms (lower and upper case conversions, sorting, etc…) And what do you need from a core string library that doesn't belong in, say, an extended package of ICU bindings? As far as I am concerned, any string operation which is defined in Unicode should be either implemented correctly (according to unicode) on the string type or not at all (and delegated to a third-party library). This means, for instance, either string comparisons should implement the UCA or they should be forbidden. This, of course, does not apply to a bytes/[w8] type, which would operate solely at the byte level. [0] http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/stringsClusters.html#//apple_ref/doc/uid/TP40008025 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] First thoughts on Rust
I guess this would be the least-bad mailing list for it considering the other one is -commits. With Rust 0.1, I finally decided to actually test Rust (kudos for a perfect compilation under OSX, by the way, no issue whatsoever to report), and have thus encountered interrogations, dislikes, or issues. And am thus reporting them here. Warning: I only spent about half an hour or an hour with rust. I'm aware some of them might have been discussed to death beforehand and can have rationales, a simple link to these discussions/rationales should be sufficient of course. Interrogations: --- * Are there plans for a CLI? Maybe not a full-blown REPL, but a basic execution console which would let users try out snippets without having to create and compile files * In the use-crate specification, are attributes arbitrary and always exactly matched? My concerns are mostly with the `vers` attribute of the examples, as strict equality is sometimes (often) not what is wanted, with richer/more flexible specifications being useful (as well as more than one spec) e.g. vers = 1.5, vers 2 - Linked to this, if some attributes have special status does Rust enforce a specific style for version numbers e.g. semver? * Are python-style chained comparison operators (e.g. `3 a 5` being true iif a is in ]3.0, 5.0[) planned? They don't seem to be possible right now, the example above fails to typecheck. * Do the rustc al libraries provide services to third-parties which would allow for easily building e.g. analysis or transformation tools (such as refactoring utilities)? Would they give AST-level access to third-party tools such as the Rust emacs mode or an IDE? I did not see any hint to documentation of these libraries and their services. Issues: --- * The first one is the apparent (community) usage of blocks for Rust's boxed closures[0]. My issue with this is that languages where blocks are first-class objects (Smalltalk, Ruby) default to non-local returns from these blocks. Rust does not — as far as I can tell — have — let alone use — non-local returns. Using block for boxed closures does everybody a disservice as it makes transition much harder and *will* disappoint people used to actual smalltalk-type blocks. The tutorial does not have this issue, which is good, but the community should be careful. Talking about lambdas or sugared lambdas would probably be a good idea (unless Rust is modified to handle and default to non-local returns from stack closures) * The second issue is both trivial and extremely serious: after having written a few trivial pieces of code (can't call them programs), it feels like Rust's handling of semicolons combines the simplicity of Erlang's with the determinism of Javascript's. I think the core issue is that Rust uses semicolons as expression separators where most if not all other braceful languages use them as expression terminators. I know the rules are simple to express, but Erlang demonstrated it would *never* feel right to people in the current state of the language. Erlang also has the issue of three different separators, but Rust has the additional issue that a semicolon becomes the difference between returning a value and returning unit. That's not right. I see three possible ways to fix this: - Don't change Rust's semantics, but change Rust's blessed style, by prefixing expressions with semicolons (instead of post-fixing). This is a common style for e.g. RelaxNG-Compact schemas and it looks correct for separators - Make semicolons into expression terminators, as in the majority of C-style languages - Add haskell-like layout rules making semicolons redundant in 99.9% of cases, and necessary only when putting multiple expressions on a line or when generating rust code mechanically. This would fix the issue by making semicolons generally unnecessary and thus not a source of error * Strings. I believe Rust's current state of conflating byte sequences and human-text strings to be as big a mistake as it was in Python. If Rust wants to be mainly bytes-oriented the `str` type should be renamed `bytes` and most string-manipulation functions should be removed. Otherwise, I believe it should be split in two clearly separate types, one manipulating sequences or arrays of bytes and the other one manipulating streams of unicode codepoints (for which encoding would be an implementation detail). I think the current setting will hurt both Rust and its users in the long term. One of the first problems being that a byte sequence advertising itself as UTF-8 and actually UTF-8 text have different properties and overlong UTF-8 (which can be found in byte sequences) is an actual security issue[1]. Bytes to string *should* require transcoding, even if that transcoding does nothing more than an O(n) shortest-form assertion
