Re: [rust-dev] 1/28 Bay Area Rust meetup: Rust 0.9 and DST
On 08/01/2014 16:58, Erick Tryzelaar wrote: Hello Rusticians! I'm happy to announce the next Bay Area Rust meetup on 1/28! You can sign up for it here: http://www.meetup.com/Rust-Bay-Area/events/153909222/ If possible it'd be awesome to post recordings here after the meetup, for those that can't physically make it. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Configuration files library for Rust
On 06/01/2014 02:45, Michael Neumann wrote: I was looking around and I couldn't find a config file parser library for Rust. Getopt support seems to be pretty complete and stable, which would make the development of such library easier. There is now a TOML parser for Rust [1] :) Thanks! /me crosses item off the todo list Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Thoughts on the Rust Roadmap
On Mon, Dec 30, 2013 at 2:00 PM, Armin Ronacher armin.ronac...@active-4.com wrote: TL;DR: please don't rush a 1.0 release. FWIW I'm all for waiting as well. That said maybe it would be worth it to discuss having a 1.0 soonish with a clear timeline that could maybe bring both sides together: - 1 or 2 years of planned BC/bugfixes/support depending on who can or wants to provide such reassurances. Therefore libs could stabilize on 1.x releases for now and more people could use rust for more than play-things, bringing more experience towards.. - a 2.0 planned with BC breaks planned for a year after the 1.0 release, which would allow broader changes to still happen in the master branch, and make sure we don't get stuck with rushed decisions for 10 years. Cheers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
On Sat, Dec 7, 2013 at 2:01 AM, spir denis.s...@gmail.com wrote:
On 12/07/2013 01:12 AM, Gaetan wrote:
I am in favor of two version of the api: from_str which has already done
the unwrap, and a from_str_safe for instance that returns a Result or
option.
This provides the important semantic information (that I've evoked at the
end end of a long earlier reply in this thread) of whether func failure is
expected and belongs to the logic of the present app and we must deal with
it, or not.
But I'm still shared on this topic for finding it also annoying, like Simon,
to have to duplicate whole catogories of such funcs (of which we cannot know
in advance whther they'll fail or not), if only the interface as apparently
proposed by Gaëtan.
Syntax sugar like this would be nice:
let str = std::str::from_utf8(Parse this optimistically, and fail otherwise);
// str is a string or the task fails
vs.
let opt_str = std::str::from_utf?(Parse this if valid); // note the
question mark
if opt_str.is_some() { }
Problem is, this sounds scary to implement at the compiler level, if
it's possible at all :) I am just throwing it out there for others to
judge.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
On Sat, Dec 7, 2013 at 2:07 AM, spir denis.s...@gmail.com wrote: Maybe it's only me, but this not at at all clear to my eyes. My imagined soluton (for a totally different lang) was something like this, on the caller side: ucodes = s.utf8_decode()! // source should be correct, error on failure ucodes = s.utf8_decode()? // logical failure expected, return None or whatnot (But maybe _this_ is obscure to your eyes?) Looks like our mails had a race condition on this one, but highlighting the cases where we expect a perfect world (i.e. !) is probably better. However, if you just call the method without anything it would be the same as calling it with ? suffix as far as I understand, so I'm not sure what the point is of keeping that one. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Practical usage of rustpkg
On Tue, Dec 3, 2013 at 8:44 PM, SiegeLord slab...@aim.com wrote: I don't think any of these options are ideal. I don't want to suggest solutions to these issues because I'm not sure how things are supposed to be used/what the planned design is. Does anybody use rustpkg seriously today? Is everybody making workspaces with a github.com/user directory where they develop their software? I usually (i.e. in other languages I work with) develop dependencies in-line as they were cloned by the package manager, at least if they need deep integration with the surrounding project and can not be easily tested/developed in isolation. It's not such a horrible situation as long as the package manager is smart enough to avoid wiping your stuff on its own. That said, a pretty good option I think is to have a command like npm link [1] that would allow you to tell rustpkg to set up a symlink to another dir on the disk, yet without interfering/polluting the project's source itself. [1] https://npmjs.org/doc/cli/npm-link.html Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton pcwal...@mozilla.com wrote: I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) I feel like I have to out myself as one of the idiot newcomers that do this, just for the sake of the discussion. I have no systems language background and frankly never had to consider the difference between the heap or the stack in the past 10-some years of writing code. I don't really think having new vs ~ would help me avoid this problem. The issue I believe is that the language looks understandable enough for the average joe used to higher level web languages (php, python, ruby). That's a great thing of course, that I can just jump in and mostly grasp what's going on, while past attempts at C++ tinkering quickly ended in tears. It also means that you have lots of people that come in and are capable of getting stuff to compile but won't necessarily understand the small print. Often there is an alternative to pooping sigils all over the code, but if you don't understand the concepts behind it it's hard to reason about what those alternatives could be. I think I'm getting better with this over time, and the rust libraries also get more usable and consistent leading to less ~ insanity, but one thing that would have helped early on is a good warning in the docs about this, and a good explanation of what the hell is going on (not one geared towards C++ devs using lingo that only low level devs are familiar with). I realize it's no easy task, and that arguably I should probably just read a book, but at the same time it's an amazing feat I think that the language is so accessible while remaining at such a low level, so if we manage to improve the onboarding process it would probably be very beneficial. There are tons of web devs that are interested in doing things faster/lower level - if only for fun. Maybe it's worth having a chapter for them in the docs. I'd happily help review that and point out unclear things :) Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM at FOSDEM 2014 - Call for papers and participation
Kind of sad nobody else seemed interested in this. I unfortunately don't know enough about rust internals to make any sensible contribution to a LLVM track, but I plan on going to FOSDEM this year so if anyone else is going I'd be happy to say hi! Cheers On Wed, Oct 9, 2013 at 2:20 PM, Sylvestre Ledru sylves...@debian.org wrote: Since rust is using LLVM, some developers might be interested by the following message (and a talk about rust itself would be much appreciated). CALL FOR PAPERS / PARTICIPATION At FOSDEM 2014, LLVM will for the first time participate with a dedicated devroom. Complementing the upcoming Euro LLVM 2014, the devroom at FOSDEM provides a great opportunity for core LLVM developers and the wider open source community to get together, connect and discuss. As possibly the largest European Open Source Conference, FOSDEM takes place in Brussels and attracts with more than 400 lectures every year over 5000 hackers - many core contributors of the worlds leading open source projects. = Call for Speakers, Posters, Demos = We invite academic, industrial and hobbyist speakers to present their work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. We are looking for: 1. Keynote speakers. 2. Technical presentations (30 minutes plus questions and discussion) related to development of LLVM, Clang etc. 3. Presentations about the use of LLVM, Clang in commercial or academic projects as well as in the open source world. 4. Tutorials 5. Lightning talks (5 minutes) The deadline for receiving submissions is December 1st, 2013. Speakers will be notified of acceptance or rejection by the 15th of December. Proposals that are not sufficiently detailed (talks lacking a comprehensive abstract for example) are likely to be rejected. Please create an account on the FOSDEM interface ( https://penta.fosdem.org/user/new_account ) and submit your proposal ( https://penta.fosdem.org/submission/FOSDEM14/event/new ). Please make sure you select LLVM devroom as the Track. = Registration = FOSDEM does not require any registration and is free of charge. However, we advise to arrive early in the devroom in case of important affluence. = Organisation = The mailing list llvm-devr...@lists.fosdem.org can be used to discuss issues of general interest related to the conference organization. = Financial Support = There may be a possibility of limited funding to help students or contributors who could not otherwise attend the conference. This will depend on overall sponsorship and companies' interest in supporting the event. If you need funding to attend the meeting, or can help sponsor, please tell us on llvm-devr...@lists.fosdem.org. = About LLVM = LLVM is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyse and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run-time, or idle-time (between program runs). The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. Besides LLVM, several projects have been developed on top of it like lang, LLDB, Polly or VMKit. For more information, please visit http://llvm.org/ or the conference webpage at http://llvm.org/devmtg/2014-02/ Tobias Grosser Sylvestre Ledru ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 0.8 release
On 27.09.2013 15:09, Renato Lenzi wrote: Strange thing... after installing rust 08 on W7 System rustc.exe (or rust.exe or rusti.exe) doesn't start and Windows complains: the application was unable to start correctly (0xc005). The worst thing is that reinstalling rust07 i get the same error.. now i'm without Rust :-( ideas? Most likely it's because you still have the 0.7 dlls. Check in C:\Program Files (x86)\Rust\bin\rustc\i686-pc-mingw32\bin and C:\Program Files (x86)\Rust\bin\ and remove all files ending in -0.7.dll. Hopefully that fixes it. The way to avoid this is to uninstall the previous version before installing a new one I think, but I always forget. It'd be nice if the installer would clean up older libs. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ 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 20.09.2013 22:35, Benjamin Striegel wrote: As usual, I'm highly resistant to use of the backtick because Markdown uses it pervasively. Not only would this make it very annoying to embed Markdown in strings, it can make it impossible to embed inline Rust code in Markdown editors. Let's leave the backtick as a metasyntactic symbol. I am not so sure the markdown argument stands, because it is only an issue in `inline code blocks` really. Blocks fenced with ``` or 4-space indents can contain backticks just fine, and can typically do in bash scripts. In inline blocks, you can always escape them with \` which sure isn't as nice, but I find it rare to have much more than alpha-numeric identifiers in inline blocks. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Zurich/CH Meetup
On 11.09.2013 17:26, Diggory Hardy wrote: Did anything ever happen about this? Sorry, I stopped reading the mailing list a while back... I'd be interested, if not very much involved with Rust at the moment. (I live in Basel.) Nope, only one other person got back to me (off list) so I put the idea on hold for now. Maybe I will try to start something towards end of October because I don't have much time now. I put you on the spam list then :) I imagine more people from outside the rust community could be interested in at least a first intro meetup, then we can see where to go from there. Cheers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Zurich/CH Meetup
On 11.09.2013 17:50, Luke Gorrie wrote: FYI, t'was me that replied off list, and I happen to be giving a (non-Rust) talk at Zurich IT Geeks (ETH) in an hour from now. So if anybody wants to come and have a beer afterwards then we could call that an informal Rust meetup :) I was planning on coming already, so let's say two make a party ;) Cheers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Doc comment conventions + straw poll
On 26.08.2013 04:25, Brendan Zabarauskas wrote: brson and the Style Guide seem to favour stacked line comments: https://github.com/mozilla/rust/wiki/Note-style-guide#comments Reason: it avoids the debate about whether to put stars on every line, etc. is an important point. That's sort of a valid point indeed, but since we are just doing a style guide from scratch and it's all fairly new ground, if the style guide says use style B it also avoids the debate I would say. Anyway my take on it is that C annoys me extremely because my editor does not support it. Regular // or B-style blocks get handled automatically and I can just type away and new lines are formatted as is. C seems to be unique to Rust (?), and poor editor support + being uncommon makes it inferior IMO. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Doc comment conventions + straw poll
On 26.08.2013 09:59, Jordi Boggiano wrote: Anyway my take on it is that C annoys me extremely because my editor does not support it. Regular // or B-style blocks get handled automatically and I can just type away and new lines are formatted as is. C seems to be unique to Rust (?), and poor editor support + being uncommon makes it inferior IMO. A quick search (too late I know:) shows it's a doxygen and C# thing. That'd explain why I never saw it before. My point about editor support still stands though. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Doc comment conventions + straw poll
On 26.08.2013 13:13, Corey Richardson wrote: On Mon, Aug 26, 2013 at 4:03 AM, Jordi Boggiano j.boggi...@seld.be wrote: On 26.08.2013 09:59, Jordi Boggiano wrote: Anyway my take on it is that C annoys me extremely because my editor does not support it. Regular // or B-style blocks get handled automatically and I can just type away and new lines are formatted as is. C seems to be unique to Rust (?), and poor editor support + being uncommon makes it inferior IMO. A quick search (too late I know:) shows it's a doxygen and C# thing. That'd explain why I never saw it before. My point about editor support still stands though. For what it's worth the vim file handles it well. Alright alright. Less bitching, more fixing! Sublime Text also handles it well now :) https://github.com/spadgos/sublime-jsdocs/pull/215 Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng: 95% done
On 12.08.2013 20:10, Armin Ronacher wrote: Hi, On 12/08/2013 16:33, Corey Richardson wrote: Super thanks to Jed Estep and Huon Wilson, who helped a lot with the backend. And, of course, this would have taken 3x longer and the result would have been half as good if it were not for Jordi Boggiano and his amazing work with the web frontend. Amazing work. Just one question: is there a mode where you can see all the functions, structs and members in a module on one page? Not in full with definitions and docs etc. like the current docs do. I find this particularly messy when there is more than one liner docs (which I hope we have one day;). It wouldn't be impossible to add obviously, but I'd rather focus on one use case for now, get things to work well, and then perhaps add more later as needed. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng: 95% done
On 12.08.2013 19:39, Daniel Micay wrote: A nitpick is that the markdown isn't being rendered correctly, at least not how it would be with an up-to-date pandoc. Can you give specifics? It's using the npm marked package right now with GFM (github flavoured markdown) enabled. As far as I could see from a quick scan it works fine but perhaps there are a few differences I didn't spot. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng: 95% done
On 12.08.2013 19:27, Alex Crichton wrote: This is awesome! If you're taking suggestions, it seems like one case can be improved. If you just heard about this TreeMap thing, you'd go to the dox, search for treemap (awesome live update btw), hit the first link, and then get bombarded with a *lot* of type signatures. If all you wanted to find was the signature for pop, you've got to scroll down aways and find the small pop word. It'd be kinda nice to all instance methods in a nice easily-scannable location which eventually had links with something along the lines of provided by the XXX trait or something like that. I'm also a fan of large-ish documentation pages. Currently there's only ever one method per page, but I personally prefer having all the methods all on one page. That way I can just scan up and down the page (and use anchors for links) to find what the method was that I needed. This isn't really major though. Agreed, this is still a bit confusing. There is a lot of info on structs and it's hard to display it all without making a mess, but I'll definitely try to improve this over time :) Also, it appears that type parameterization for return types isn't showing up just yet, the return value of pop is just Option, not OptionV. Thanks - I'll get that fixed, simple omission because we didn't have type params early on. Finally, perhaps all of the types/traits don't have to be listed with their full paths? It clutters up things like the Encodable implementation for TreeMap, and everything is a hyperlink anyway so it should be pretty easy to find the full path. module-local types are shown in short form, and the others are shown with fully qualified name for now. One improvement I have planned is to show short form for whatever is in the prelude as well, that should help in some cases. But yeah it is in some case a bit messy and quite long so perhaps we can do short-form everywhere with the fully qualified name in the link's title attribute. I'll play with it and see. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng: 95% done
On 12.08.2013 20:19, Patrick Walton wrote: On 8/13/13 4:15 AM, Evan Martin wrote: This is vague, I feel like there's too many clicks to get into the details of something. E.g. if I'm trying to see what the std module offers, the overview page just lists modules without any description. if I click into ascii, I see a list of functions but I need to click on each one to see what it does. In the golang world they have a convention of providing short summary docs separate from the detailed docs to avoid this; see http://golang.org/pkg/ . I often use ctl-F on that page to find what I'm looking for. Similarly if you click in to a package there -- they show the function types inline which is often a hint to their behavior. Yes, this was the first thing I noticed. I'd prefer if there were a short summary of each item next to it in the module view. It's coming :) Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng: 95% done
I noticed it because the code samples weren't syntax highlighted but there are some other quirks with lists/headers. Rust's documentation doesn't stick to the very small part of the language that's common across most implementations. It would mean no nested lists, tables, code snippets, definition lists, formulas, etc. http://johnmacfarlane.net/pandoc/demo/example9/pandocs-markdown.html OK, well the syntax highlighting is another problem, the lib I'm using seems to have an out of date rust syntax or something and it fails hard when trying to highlight blocks so I temporarily disabled it. nested lists and tables are supported, code blocks too. definition lists can be inlined in html in the docs if really needed, formulas I have no idea. The bottom line is most things are possible too with GFM and it is my opinion that it's more common/well-known than pandoc given that pretty much everyone these days uses github at some point or another. So I would say if that's ok we switch whatever few things don't work from the pandoc syntax over to GFM syntax. Is this acceptable? I don't mind helping with it, but it would help if people report any incompatibilities then. Cheers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng: 95% done
On 12.08.2013 22:47, Jeaye wrote: Searching for std::hashmap::HashMap, I typed Hash. When the ideal results didn't show up, I added an 'M' to make my query HashM at this point, I'm told nothing is found and that I should try DDG. However, if I continue to type 'ap' to make my query HashMap, I get proper results. This seems broken to me; do you know about it? Yes search is now a bit dumb and kinda only does exact matches. It's a decent search engine for natural language stuff, but does not scale very well to the needs we have. Ultimately I hope someone will find the time to rewrite it, but for now it's not the top priority. If you'd like to help obviously feel free to get in touch :) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Zurich/CH Meetup
Heya, I know this is a long shot given I don't see many EU people on IRC, but would there be anyone around Zurich or in Switzerland at all that wants to gather up for a small Rust meetup (or we can just go have a beer)? Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Java versus .NET style for acronyms in type names
On 03.08.2013 03:28, Patrick Walton wrote: Hi everyone, Brendan Eich emailed me expressing a preference for `GC` over `Gc`. I think now is as good a time as any to have the bikeshedding debate :) I've noticed two styles for acronyms in type names: Java style (HTTPServer) versus .NET style (HttpServer). Currently we are usually using .NET style, but inconsistently (e.g. ARC). We never really decided. Here are a few examples of types in each style: * Java style: GCFoo, ARCint, SimpleHTTPServer, XMLHTTPRequest. * .NET style: GcFoo, Arcint, SimpleHttpServer, XmlHttpRequest. I slightly prefer Java style myself because I think GC looks better than Gc, because Web APIs use Java style, and because Python does (e.g. SimpleHTTPServer) and in general we've been following PEP 8. But I don't feel strongly on this issue. Thoughts/straw poll? I prefer Java style visually (mostly, more below), but I prefer .NET for the consistency that it brings, and the simplicity of the rule. Just studly-caps on words, no matter what they are. It makes things less ambiguous, for HTTP it's obvious, but for ARC if someone tells you to use that and pronounces it arc and not A R C you might not know it's an acronym and just write Arc and waste time. I can't think of a more valid example right now but I think they're out there. Also XMLHTTPRequest is frankly nasty, it's as readable as German word-combination to the uninitiated. If you don't know what XML and HTTP are, good luck finding out there are two different words in there (again just an example). So I'd say better keep heading towards .NET (BTW Arc has been renamed to that already I think?) and standardize on that. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] rustdoc_ng and normalization of documentation
Heya, I have been planning/scheming a new doc web frontend to go with cmr's rustdoc_ng and in the process I ran into the question of normalization and structuring of the documentation blocks. If we take the net::tcp::accept function for example [1], it has fairly extensive documentation but the way it is rendered in the web docs is just a 1:1 markdown to html conversion. For me the Arguments and Returns blocks should come before the example in the documentation, because this is usually shorter and more important. In the source though keeping these close to the bottom is pretty nice because it keeps them closer to the function signature and the code itself. I see a few options to handle this going forward: - Full reorganization of the doc blocks with special tags/annotations à la javadoc [2], I am not a particular fan of that but for special things it does serve it's purpose and has the advantage of being somewhat widespread. - We standardize on a few heading names like Arguments/Returns/Example/Changes so that those blocks can be extracted and displayed in the preferred order in the docs, and whatever remains is appended after. - Stand-still / keep a free-form format What would everyone prefer? Any other approach? [1] http://static.rust-lang.org/doc/extra/net_tcp.html#function-accept [2] http://en.wikipedia.org/wiki/Javadoc Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng and normalization of documentation
On 15.07.2013 15:07, Corey Richardson wrote: On Mon, Jul 15, 2013 at 9:03 AM, Jordi Boggiano j.boggi...@seld.be wrote: [snip] - Full reorganization of the doc blocks with special tags/annotations à la javadoc [2], I am not a particular fan of that but for special things it does serve it's purpose and has the advantage of being somewhat widespread. For some things, we can attach an attribute to the item. For example, https://github.com/mozilla/rust/issues/723 would be included in the documentation somehow, rather than the Javadoc-like solution of in-comment annotation. Interesting indeed, and definitely when possible I would favor real annotations to in-comment ones, that way the code won't compile unless the docs format is valid. However as bjz mentioned [1] it would be nice to have more metadata attached to it like an alternative and date/version at which it will disappear. [1] https://github.com/mozilla/rust/issues/723#issuecomment-10351828 Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] github security flaw, bors review
On 25.06.2013 05:17, Graydon Hoare wrote: On 13-06-24 08:15 PM, Graydon Hoare wrote: On 13-06-24 07:05 PM, Daniel Micay wrote: Also, not just the head commit because someone could reset and force push. :P Bors only pays attention to comments on the head commit, and comments on commits adhere to that specific sha1 only. This is intentional. The part where users can edit other people's comments is .. not. I mean, maybe github thinks it's a great idea to edit other people's words. Maybe it was their intent. I was not aware of this feature and it works counter to the intended security design of bors. Hence this thread. I don't really know the existing system, but how about you change it to read comments on the pull request and not the commits? Those comments can only be edited by repo owners of the pull request target, and those people already have access to the merge button so there is very little risk for abuse I imagine. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Update on I/O progress
Take my input with a grain of salt since I'm so new to the language, but here goes nothing: I am particularly interested in making sure that common operations are convenient and don't require a lot of boilerplate. To that end I've been collecting [aspirational examples] of succinctly written Rust I/O code using the hypothetical API. The goal will be to turn these into test cases. I welcome additional examples. One fairly common (at least to me) case I would like addressed is TCP reads/writes with timeouts. It's quite common when writing anything network related that you need to handle timeouts to be able to kill the connection and retry or abort. If you don't you easily end up with zombie processes. In the current net::tcp it seems possible using the raw socket, but not if you use any of the convenience of TcpSocketBuf. I'm not sure how this would be best implemented, but I just wanted to raise the issue before it's too late and we have to write lots of boilerplate task monitoring to have timeouts. Which is ok but a bit hard on newcomers. ## Error handling I've spent a lot of time thinking about - and talking to Patrick about - how I/O should deal with errors (the old `io` doesn't have a consistent strategy). The [error handling strategy] I'm proposing is intended to eliminate boilerplate and allow efficient recovery from errors, but it uses some uncommon patterns. This seems suboptimal still. Reading your [error handling] example, I wonder if this is really better than traditional exceptions that would break the execution after the failed `new` call. Now this might not be practical to implement in rust, so I'll skip over that and assume conditions are good. You say that both `new` and `write_line` will raise a condition in this case, but that means `error` at the end contains the second condition, which probably would have a message like could not write in a null file or something. While the message that interests us, for debugging or printing out to the user, is the first one could not open file because of X. I fear that in the end to be able to handle and report errors properly one would have to write so much condition handling boilerplate that simply relying on multiple return values à la Go might be best. [error handling] https://github.com/brson/rust/blob/io/src/libcore/rt/io/mod.rs#L155-164 ## Close Do we need to have `close` methods or do we depend solely on RAII for closing streams? I would say yes, because sometimes you really need to release a file to be able to do other things with it (especially on windows which likes to lock files for various reasons). ## Constructor options I am considering defining `open` more like `fn open:S: OpenSpec(spec: S)`, then implementing `OpenSpec` for e.g. `str`, `Path`, `(Path, FileFlags, FileAccess), `Url`, etc. Does this seem reasonable? Feels weird to have str implement something specific to another module, but if there is no other way it sounds more user friendly than a gazillion open_* methods. A few more comments on other things: - Streams are great, and the ability to register new stream protocol handler for foo:... urls would indeed be a big plus. - File vs FileStream, you could have a File (FileStream) and a FileInfo for the info stuff, since the latter is less commonly used. - open vs connect, I'd say open. Opening a connection sounds ok, connecting a file sounds awkward. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
