Re: [rust-dev] Recommendations for a GUI toolkit for rust
To my opinion qt is far better, more portable, more easy to work with, but binding qt on rust is quite a challenge. I think binding gtk3 is much easier, however I don't think there is any project ready for production yet. Le mardi 25 novembre 2014, Prasoon Shukla prasoon92.i...@gmail.com a écrit : Hey all I have been thinking of making a small text editor, with emacs-like fundamentals, as a way learning rust this winter break. I need a GUI toolkit for this, of course. So, I searched for it and found this page: https://github.com/kud1ing/awesome-rust This page gives a few choices to me and since everything is alpha right now (both the language and the toolkits), I don't know which one to choose. As a reference, I have used GTK+ before and so, I could probably use it again https://github.com/JeremyLetang/rgtk. However, my primary concern is that the toolkit I use would stop active development - I don't want to have to port everything to another toolkit later on. So, if any project shows promise of continuing, please suggest it to me. Thank you. ᐧ -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Meetup Rust Paris 02.
Sad, I go to paris the 2rd of Apr :( - Gaetan 2014-03-19 16:23 GMT+01:00 Axel Viala axel.vi...@darnuria.eu: Hello Rusties! I am glad to announce the 2nd Meetup rust in Paris: https://reps.mozilla.org/e/meetup-rust-paris-02/ If you want to come please sign up as Mozillian and or put your name here: https://etherpad.mozilla.org/remo-meetup-rust-paris-02 Thanks! If you have any question feel free to reply! :) ___ 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] Doc sprint planning
Hello Here are some reference documentation I found really powerful, all information are here, presented the right way. Each have its different approach. I would be good that the Rust documentation use the same pattern for each doc. - QT Doc: http://qt-project.org/doc/qt-4.8/qthread.html / http://qt-project.org/doc/qt-4.8/qatomicint.html (introduction parts are big, and place the context where to use each API, gives lot of examples) - Python documentation reference http://docs.python.org/2/library/urllib2.html (functions are ordered by importance) - Boost documentation ( http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/gregorian.html) is exhaustive on some API, but extremely hard to read, mostly because they are divided in many pages. My 2 cents. Gaetan - Gaetan 2014-03-12 0:52 GMT+01:00 Erick Tryzelaar erick.tryzel...@gmail.com: Thanks for this. This sounds great. We should form a group on Thursday at the meetup and come up with that checklist. I can help track down the doc-less APIs Friday night and some of Saturday too. On Mon, Mar 10, 2014 at 5:38 PM, Brian Anderson bander...@mozilla.comwrote: Hey, As you may know, we've got our first doc sprint scheduled for Sunday, 12-4 Pacific time. We'll to set up the commons area at the SF office with pizza and turn on video conferencing for remoties. Before that day comes though we need to come up with some kind of plan, something that is simple and fun. Here's my strawman proposal for what we're going to do Sunday: We'll focus on API docs since those are bitesize units of work and extremely parallelizable. Before the event we come up with a checklist for what API docs should include, as well as a list of high-value API's with missing docs. Sunday we put that list on an etherpad, and let people claim individual functions, traits, etc. Additionally, we keep a 'scoreboard' to track who completes the most docs. Whoever has the most docs at the end wins (just pizza and accolades). Does this sound reasonable? Does anybody want to volunteer to 'run' the sprint (make the list of needed docs, help people find tasks, collect and upstream the results, etc.)? Regards, Brian ___ 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] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)
I really like anaconda with sublime. Even if the module is not perfectly parsable, it can display you the right info, with some kind of heuristic to fix type mistakes,... Le 12 mars 2014 22:42, Clark Gaebel cgae...@uwaterloo.ca a écrit : Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) On Mar 12, 2014 4:53 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 04:11 PM, Clark Gaebel wrote: Honestly, I like the 98% solution of grab metadata from every other module in the project except the one you're editing, and use 'text that appears before' completion (or similar heuristics) for things in the module you're editing. It doesn't require a compiler that can parse broken code, and is relatively minimal in work. How do you find the type of the value you're trying to complete a method on, like `foo.btab`? You need to be able to identify the type and the in-scope traits. ___ 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
discutions go steril here. Let's cut this thread - Gaetan 2014-03-05 9:59 GMT+01:00 John Mija jon...@proinbox.com: Although you use Rust as main language, there are reasons to use a second language i.e. for scripting; the AAA games usually are built in C++ but it's very common the usage of Lua for scripting El 05/03/14 04:40, Liigo Zhuang escribió: If I select Rust as my main language, I don't think I have any reason to write new code in Go. Go away! 2014年3月5日 上午3:44于 John Mija jon...@proinbox.com mailto:jon...@proinbox.com写道： Every time there is a new language, developers have to start to developing from scratch the same algorithms. The alternative has been to use C libraries already built since is much easier to interface with other languages and a lot of languages will let you call C functions directly. But C language is unsafe and there is a penalty performance at binding. Besides, it is harder to debug incorrect C code. So, why don't use a simple language but safe like Go? The Go compilers create a single intermediate file representing the binary assembly of the compiled package, ready as input for the linker: http://golang.org/cmd/gc/ I'm supposed that a linker could be built to link that intermediate file together to a Rust program. The main advantage is that you would use a simpler language to build algorithms and code of lower level (asm), wich could be linked from other languages. Rust is a language more complex to replace to C like universal language. Note: I love both languages; Go for web apps and Rust for everything else (mobile and desktop apps, and servers). _ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/__listinfo/rust-dev 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] Rust-dev Digest, Vol 44, Issue 70
I also love to be part of it if you set up a github project I'll be glad to send some PL on this subject - Gaetan 2014-02-19 14:43 GMT+01:00 Daniel Fath daniel.fa...@gmail.com: Hi everyone, So I would like to know if anyone else working on this and to read your comments on the JSR 310 choice. I was interested but day job, master thesis and my own XML parser got in the way :( If you are starting I'd love to join and help you, but I have a LOT of reading on my plate. From what I've gathered you best start from ISO-8601 add the Olson time database and basically build from there. Sincerely, -Y- On Wed, Feb 19, 2014 at 4:38 AM, rust-dev-requ...@mozilla.org wrote: Send Rust-dev mailing list submissions to rust-dev@mozilla.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.mozilla.org/listinfo/rust-dev or, via email, send a message with subject or body 'help' to rust-dev-requ...@mozilla.org You can reach the person managing the list at rust-dev-ow...@mozilla.org When replying, please edit your Subject line so it is more specific than Re: Contents of Rust-dev digest... Today's Topics: 1. lib: Datetime library (Alfredos (fredy) Damkalis) 2. RFC: About the library stabilization process (Brian Anderson) 3. Re: RFC: About the library stabilization process (Huon Wilson) 4. Re: issue numbers in commit messages (Benjamin Striegel) -- Message: 1 Date: Tue, 18 Feb 2014 23:52:45 +0200 From: Alfredos (fredy) Damkalis fr...@fredy.gr To: rust-dev@mozilla.org Subject: [rust-dev] lib: Datetime library Message-ID: 5303d62d.9050...@fredy.gr Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, I am new to rust and interested in writing datetime library. I have already read most of the linked documents and code gathered by Luis de Bethencourt and others in wiki page [1]. I have also read the thread [2] where Luis offered his help on writing this library. I have talked to Luis and unfortunately he is busy these days, so I have offered to continue his work. Searching about datetime libraries ended up to JSR 310 [3] which was also mentioned in the previous thread [2]. This specification is in final draft state and it seems to be the most complete one out there about datetime libraries. You can take a quick look at its basic ideas in a recent article [4] in java magazine. I am also aware of Ted Horst's work[5] where the last commits look like maintenance work. I am not sure if he is going to expand his library, unfortunately I didn't have the chance to talk to him. So I would like to know if anyone else working on this and to read your comments on the JSR 310 choice. Thank you, fredy [1] https://github.com/mozilla/rust/wiki/Lib-datetime [2] https://mail.mozilla.org/pipermail/rust-dev/2013-September/005528.html [3] https://jcp.org/en/jsr/detail?id=310 [4] http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html [5] https://github.com/tedhorst/rust_datetime -- Message: 2 Date: Tue, 18 Feb 2014 17:40:26 -0800 From: Brian Anderson bander...@mozilla.com To: rust-dev@mozilla.org rust-dev@mozilla.org Subject: [rust-dev] RFC: About the library stabilization process Message-ID: 53040b8a.5070...@mozilla.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hey there. I'd like to start the long process of stabilizing the libraries, and this is the opening salvo. This process and the tooling to support it has been percolating on the issue tracker for a while, but this is a summary of how I expect it to work. Assuming everybody feels good about it, we'll start trying to make some simple API's stable starting later this week or next. # What is the stability index and stability attributes? The stability index is a way of tracking, at the item level, which library features are safe to use backwards-compatibly. The intent is that the checks for stability catch all backwards-incompatible uses of library features. Between feature gates and stability The stability index of any particular item can be manually applied with stability attributes, like `#[unstable]`. These definitions are taken directly from the node.js documentation. node.js additionally defines the 'locked' and 'frozen' levels, but I don't think we need them yet. * Stability: 0 - Deprecated This feature is known to be problematic, and changes are planned. Do not rely on it. Use of the feature may cause warnings. Backwards compatibility should not be expected. * Stability: 1 - Experimental This feature was introduced recently, and may change or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team. * Stability: 2
Re: [rust-dev] Improving our patch review and approval process (Hopefully)
Travis is well for unit testing with already existing compiler, however here I dont see how you will deploy the stage0 easily for automating. I think you should stick with your buildbot and improve it in order to enhance pre merge tests on PL (why not trigger the test when the creator of the PL set it in ready mode, like a dedicated comment you use for merge. This will add a lot of load on your build server however. my 0.01 euros. - Gaetan 2014-02-20 0:46 GMT+01:00 Ben Noordhuis i...@bnoordhuis.nl: On Wed, Feb 19, 2014 at 11:53 PM, Alex Crichton a...@crichton.co wrote: Currently, all patches are being tested after they are approved. However, I think it would be of great benefit for contributors - and reviewers - to test patches before and after they're approved. I would personally love to explore using Travis-CI for this. I think this is almost exactly what travis was built for. That being said, there's no way that travis could handle a full `make check` for rust. However, perhaps travis could handle `make check-stage0-lite` (not that this rule exists yet). I think we would have to figure out how to avoid building LLVM, but beyond that we *should* be able to run a bunch of stage0 tests and optimistically print out the results of the PR. This obviously won't catch many classes of bugs, but perhaps it would be good enough for a preemptive check. The best part about this is that it's almost 0 overhead of automation for us because travis would handle all of it. $0.02 from the node.js and libuv camp: we have used Travis in the past but there were so many spurious test failures (with no way to debug them) that we moved to dedicated Jenkins instances. In my experience, anything involving I/O is hit and miss with Travis. ___ 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] issue numbers in commit messages
It is generally a good practice to embed the information of the tracking tool inside the git commit message so finding this information is straight forward, and you can jump from any commit to the GitHub issue also instaneously. We use Gerrit with a tracked-on field on the last paragraph of the commit message (which is supported by gerrit) in order to link this commit to our tracking tool. Github seems to support only #123 substring in the commit message. Beware because it will close automatically the issue if the string Fix #123 is found in the first line, and a single commit can refer to more than only one github issue. My 2 cents, - Gaetan 2014-02-17 23:43 GMT+01:00 Palmer Cox palmer...@gmail.com: I believe that bors never does a fast forward merge and that the merge commits always contain the pull number. So, if you have a particular commit and you want to find the issue that it was part of, I believe you can always look look through its children until you find a commit by bors which should have a commit message like: auto merge of #12313 : bjz/rust/tuple, r=huonw which contains the issue number. Let says that the commit you are interested in is 6f39eb1. I think if you run the command: git log --author bors --ancestry-path 6f39eb1..origin/master And look at the commit at the very bottom of the list, that will be the merge commit that you are interested in. I'm not a git expert - there may be a better way to do that. -Palmer Cox On Mon, Feb 17, 2014 at 4:50 PM, Nick Cameron n...@ncameron.org wrote: How would people feel about a requirement for all commit messages to have an issue number in them? And could we make bors enforce that? The reason is that GitHub is very bad at being able to trace back a commit to the issue it fixes (sometimes it manages, but not always). Not being able to find the discussion around a commit is extremely annoying. Cheers, Nick ___ 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] What form should the official Rust binary installers for Unixes take?
You ll need to create many binary packages : Ubuntu (10.04, 10.10, 11.04, 11.10, 12.04, 12.10, 13.04, 13.10), debian, homebrew, Windows,... There is a huge among of work. Le 9 févr. 2014 16:40, Daniel Micay danielmi...@gmail.com a écrit : On Sun, Feb 9, 2014 at 8:36 AM, Simon Sapin simon.sa...@exyr.org wrote: On 07/02/2014 00:35, Brian Anderson wrote: We can also attempt to package Rust with various of the most common package managers: homebrew, macports, dpkg, rpm. In my experience with WeasyPrint, this only works if the person maintaining one of these packages uses it personally. (Scratch your own itch.) This probably excludes most contributors, as they will have a git clone built from source to work with. Alternatively, this may be viable if these packages can be *entirely* automated as part of the normal build/release system, so that they don't really need maintainance. But I don't know if that's possible. I certainly use my nightly Arch package even though I usually have a build or two of local branches around. It's very convenient to always have a working install of master that's less than a day old. It's built automatically and in theory doesn't require any attention. Rust's Makefile does love to break though... ___ 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] Deprecating rustpkg
There is not only API change. Sometime, from a minor version to another, a feature get silently broken (that is silent regression). While it might not impact libA which depends on it, but it may fail libB which also depends on it, but with a previous version. As a result, libA force installation of this dependency without any concern (all its features works) but libB get broken without any concern. And that the real mess to deal with. That's happened this week at my job... I largely prefer each library be self contained, ie, if libA depends on libZ version X.X.X, and libB depends on libZZ version Y.Y.Y, just let each one be installed and used at there own version. That is perfectly acceptable (and even recommended) for a non system integrated software (for example when a companie want to build a software with minimum system dependency that would run on any version of Ubuntu, with the only dependency on libc. On the other hand, when the software get integrated into the distribution (ubuntu, redhat, homebrew), let the distrib version manager do its job. - Gaetan 2014-02-01 Tony Arcieri basc...@gmail.com: On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden leebr...@gmail.com wrote: This would be counterproductive. If a library cannot be upgraded to 1.9, or even 2.2, because some app REQUIRES 1.4, then that causes SERIOUS, SECURITY issues. Yes, these are exactly the types of problems I want to help solve. Many people on this thread are talking about pinning to specific versions of libraries. This will prevent upgrades in the event of a security problem. Good dependency resolvers work on constraints, not specific versions. The ONLY realistic way I can see to solve this, is to have all higher version numbers of the same package be backwards compatible, and have incompatible packages be DIFFERENT packages, as I mentioned before. Really, there is a contract here: an API contract. Are you familiar with semantic versioning? http://semver.org/ Semantic Versioning would stipulate that a backwards incompatible change in an API would necessitate a MAJOR version bump. This indicates a break in the original contract. Ideally if people are using multiple major versions of the same package, and a security vulnerability is discovered which affects all versions of a package, that the package maintainers release a hotfix for all major versions. -- Tony Arcieri ___ 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] Deprecating rustpkg
why not enforcing in a way or another a API compatibility test suite for ensuring at least a certain level of compatibility between two version? I think it is something quite doable, and moreover this would kinda force the package manager to write unit tests which is always a good practice. - Gaetan 2014-01-31 Sean McArthur s...@seanmonstar.com: On Fri, Jan 31, 2014 at 1:05 PM, Tony Arcieri basc...@gmail.com wrote: IMO, a system that respects semantic versioning, allows you to constrain the dependency to a particular *major* version without requiring pinning to a *specific* version. I would call anything that requires pinning to a specific version an antipattern. Among other things, pinning to specific versions precludes software updates which may be security-critical. It's perfectly reasonable to require a certain *minor* version, since minor versions (in semver) can include API additions that you may depend on. Also, nodejs and npm supposedly support semver, but it's impossible to enforce library authors actually do this, so you'll get libraries with breaking changes going from 1.1.2 to 1.1.3 because reasons. ___ 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] Deprecating rustpkg
Le vendredi 31 janvier 2014, Val Markovic v...@markovic.io a écrit : .This is a huge problem in large C++ codebases. It is not fun. An example: every version of Xerces-C++ puts its code in a new C++ namespacehttp://xerces.apache.org/xerces-c/program-others-3.html, so code is in xerces_3_0, xerces_3_1, xerces_3_2 etc to prevent these kinds of issues. We did that at work, this seems to be the unique, practical solution. I don't like when I see a hash in the library file name or symbol name, but this very efficient for easily manage inter dependency. -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Deprecating rustpkg
1) If a minor change or bugfix happens, increment the minor version. 2) If a major change, which is backwards compatible (i.e., new features) happens, then increment the major version. 3) When loading libraries, you can specify a major and a minor version, with 0 for the minor version if you like. You get at least that version, or better, or the loading fails. 4) If an incompatible change happens, then it's not fulfilling the same library API any more, so you stop trying to force square pegs into round holes, and **just rename the damn thing** ;) ;) Rule 4 seems to be where every other OS's libraries makes a big mistake. It's a matter of politics. You can't choose for every project. Just let people choose what is best for them. Versionning system for each project is different, versionning on windows libraries is different than on linux or mac. For the internet age, there are new complexities of decentralised forks, I think we'd need a few more rules: 5) Library names have namespaces, something like Java's (and go's?) com.org.libname system I hate this. Even if this is very logicial, it's anti ergonomic. What more ugly than having the first directory in you source base named com or org.. 6) Anything unofficial (i.e., your patch to version 1.3, bringing it to an UNOFFICIAL version 1.4) goes in your own namespace, until accepted into the official codebase, OR you fork your own, NEW, incompatible library, as in (4)+(5). -- Lee ___ 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] let mut - var
I like the fact that is more expensive to write let mut than let. So you initialize mutable variable on purpose Le 30 janv. 2014 05:31, Haoyi Li haoyi...@gmail.com a écrit : Sorry to parachute in to the conversation (long time lurker) but just to add to the statistics, the Scala standard library and compiler has 11875:54575 ratio of mutable (var) vs immutable (val) declarations, so it seems to match pretty well with the numbers you guys are seeing in the rust libraries. On Thu, Jan 30, 2014 at 12:18 PM, Samuel Williams space.ship.travel...@gmail.com wrote: Jason, I haven't actually written any rust code (yet). I'm just commenting based on reading other people's code - it was something I noticed in a few examples - it might have been bad form (assuming that mutable data are the Wrong Thing?). I brought it up because I wasn't sure if it was something that had been considered. It made the code I was reading look a bit clunky (which appears to be the desired result). On 30 January 2014 17:07, Jason Fager jfa...@gmail.com wrote: You *should* get sick of writing 'let mut' all over the place, not just b/c of the syntax but b/c you're using mutable variables all over the place. Casual mutability kills maintainability. Affordances matter. I'm convinced that the reason Option.unwrap() is used so frequently is b/c it's the shortest method name and requires the fewest explicit decisions, and so is the easiest thing to reach for. If it were unwrap_or_fail(reason), forcing you to both type more and to think about a fail message, unwrap_or and unwrap_or_else wouldn't look as difficult in comparison. or and or_else would be even better, or 'do' syntax now that the keyword's free again. Make the Right Thing the easy thing, and don't put effort into making the Wrong Thing as easy or easier. On Wednesday, January 29, 2014, Samuel Williams space.ship.travel...@gmail.com wrote: I agree that it is syntactic salt and that the design is to discourage mutability. I actually appreciate that point as a programmer. w.r.t. this specific issue: I think what concerns me is that it is quite a high burden for new programmers (I teach COSC1xx courses to new students so I have some idea about the level of new programmers). For example, you need to know more detail about what is going on - new programmers would find that difficult as it is one more concept to overflow their heads. Adding var as a keyword identically maps to new programmer's expectations from JavaScript. Writing a program entirely using var wouldn't cause any problems right? But, could be optimised more (potentially) if using let for immutable parts. Anyway, I'm not convinced either way, I'm not sure I see the entire picture yet. But, if I was writing code, I'd certainly get sick of writing let mut over and over again - and looking at existing rust examples, that certainly seems like the norm.. On 30 January 2014 15:59, Samuel Williams space.ship.travel...@gmail.com wrote: I guess the main gain would be less typing of what seems to be a reasonably common sequence, and the formalisation of a particular semantic pattern which makes it easier to recognise the code when you visually scanning it. On 30 January 2014 15:50, Kevin Ballard ke...@sb.org wrote: On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@mozilla.com wrote: On 01/29/2014 06:35 PM, Patrick Walton wrote: On 1/29/14 6:34 PM, Samuel Williams wrote: Perhaps this has been considered already, but when I'm reading rust code let mut just seems to stick out all over the place. Why not add a var keyword that does the same thing? I think there are lots of good and bad reasons to do this or not do it, but I just wanted to propose the idea and see what other people are thinking. `let` takes a pattern. `mut` is a modifier on variables in a pattern. It is reasonable to write `let (x, mut y) = ...`, `let (mut x, y) = ...`, `let (mut x, mut y) = ...`, and so forth. Having a special var syntax would defeat this orthogonality. `var` could potentially just be special-case sugar for `let mut`. To what end? Users still need to know about `mut` for all the other uses of patterns. This would reserve a new keyword and appear to duplicate functionality for no gain. -Kevin ___ 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Deprecating rustpkg
I also agree on the task force proposal, it's the right way to capitalize
on past failure and success.
For me, rust-pkg will not success if it doesn't have a proper centralized
repository. That's a debate, the current version explicitely specify the
URL where to download stuff. But things changes, developers changes, URL
get broken, or a new developer forks a project or continue it on another
repository.
I have quite a good experience (I think) on dependency management, mostly
on C++ (QT/Linux projects and embedded) and now python (that's why I love
the simplicity and power of pipy!) so I would be glad to be associated with
such task force. For me you have two approach: enough for major use case,
things like pipy that do the job for most use case, and exhaustive
approach where you end up with complicated but extremely powerful
do-it-all tools like maven but that get eventually dropped because it's too
complex to use.
That is also joining the build system thread, where also rustpkg appeared
:) But I push to split them appart: the dependency management tool should
trigger a build system and not do everything
-
Gaetan
2014-01-28 Huon Wilson dbau...@gmail.com
On 28/01/14 19:36, György Andrasek wrote:
I never quite understood the problem `rustpkg` was meant to solve. For
building Rust code, `rustc --out-dir build` is good enough. For running
tests and benchmarks, `rustc` is good enough. For downloading things, I
still need to feed it a github address, which kinda takes away any value it
could have over `git clone` or git submodules.
rustpkg (theoretically) manages fetching and building dependencies (with
the appropriate versions), as well as making sure those dependencies can be
found (i.e. what the -L flag does for rustc).
What I would actually need from a build system, i.e. finding {C,C++,Rust}
libraries, building {C,C++,Rust} libraries/executables and linking them to
said {C,C++,Rust} libraries, it doesn't do. It also doesn't bootstrap rustc.
rustpkg is unfinished and has several bugs, so describing its current
behaviour/usage as if it were its intended behaviour/usage is not correct.
I believe it was designed to handle native (non-Rust) dependencies to some
degree.
Huon
[Disclaimer: I've never quite got a rustpkg workflow going. It's probably
awesome, but completely overshadowed by `rustc`.]
On 01/28/2014 09:02 AM, Tim Chevalier wrote:
On Mon, Jan 27, 2014 at 10:20 PM, Val Markovic v...@markovic.io wrote:
On Jan 27, 2014 8:53 PM, Jeremy Ong jeremyc...@gmail.com wrote:
I'm somewhat new to the Rust dev scene. Would anybody care to summarize
roughly what the deficiencies are in the existing system in the
interest of
forward progress? It may help seed the discussion for the next effort
as
well.
I'd like to second this request. I haven't used rustpkg myself but I've
read
its reference manual (
https://github.com/mozilla/rust/blob/master/doc/rustpkg.md) and it
sounds
like a reasonable design. Again, since I haven't used it, I'm sure I'm
missing some obvious flaws.
Thirded. I implemented rustpkg as it's currently known, and did so in
the open, detailing what I was thinking about in a series of
exhaustively detailed blog posts. Since few people seemed very
interested in providing feedback on it as I was developing it (with
the exception of Graydon, who also worked on the initial design), I
assumed that it was on the right track. I rewrote rustpkg because
there was a perception that the initial design of rustpkg was not on
the right track, nor was cargo, but obviously simply rewriting the
whole system from scratch in the hopes that it would be better didn't
work, since people are talking about throwing it out. So, before
anybody embarks on a third rewrite in the hopes that *that* will be
better, I suggest that a working group form to look at what went wrong
in the past 2 or 3 attempts at implementing a build system / package
system for Rust, so that those mistakes can be learned from. Perhaps
all that needs to be done differently is that someone more central to
the community needs to write it, but if that's what it takes, it seems
preferable to the wasted time and effort that I imagine will ensue
from yet another rewrite for the sake of throwing out code.
Cheers,
Tim
___
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] Modules and visibility
I don't see the point to link the logical structure of the code with the IDE or editor you use. There is no link between them, or it is a good practice NOT to do any assumption. If one want to code with vi/emacs/sublime or eclipse or any other one, the build system and structure of the code should be agnostic. For me the current structure of code of rust is totaly acceptable, even though I would recommend to place unit test in a submodule of the tested one (ie just splitting the code and its unit test in two files), but that is just a policy you can enforce in your project (is there a lint for that?). Same for the one class per module. Maybe having triggerable linter can help people choosing there convention. What really annoy me is the fact that public method/class are not easilly described in one place. On one hand, I like the headers in C++ where you have a clear way of seeing which are the class/function your module provides, with private stuff being pushed aside. To be more accurate, I like the declaration/definition splitting of function. However the python or java way is really handful where you just write the code directly. I don't know which is best, I have the feeling rust is in the middle, but I sometime don't see clearly in the rust code the list of public methods of a given class. Maybe there is room for improvement. For the internal visibility, I really enjoy the python's way of life you can access to anything at your own risk, however I finally don't think it's a good practice. If you end up doing that, your design is wrong... except for unit test where is it really useful to have direct and easy access to private member to mock it... - Gaetan 2014/1/24 Patrick Walton pcwal...@mozilla.com On 1/23/14 8:39 PM, Damien Radtke wrote: I will say that I actually really like Go's approach to modules. It uses a folder - module mapping instead, so a module can consist of any number of source files provided they all live in the same directory. If you prefer your modules to be one big source file each, then that's easily done, but those who want to break a module up into several files can do so easily. My issue with Go's approach is that you lose the ability to see where an identifier came from by simply searching through the buffer you have open; you have to grep in the current directory. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Modules and visibility
I've started to work on better implementation of ctags. - Gaetan 2014/1/24 Lee Braiden leebr...@gmail.com On 23/01/14 22:23, Steve Klabnik wrote: Ehhh, my phrasing on that one was poor. What I was trying to say is that there are a significant number of users of Rust who do not have IDEs, and adding anything that would _require_ you to use an IDE with Rust is a significant drawback. If an IDE floats your boat, no complaints from me. As long as I can use my vim, I don't care what you use. :) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Even many serious vim / emacs users have it tweaked to the point where it does a lot of IDE-like things, such as completion and project file switching / builds / tag search too. I think the need is to support IDE features in a flexible way, that any editor / IDE can interface with as suits them. I think the best solution to that would be some sort of daemon that takes a top-level project definition, or a set of files, compiles them, monitors for changes, and interactively answers questions about it via some simple API: // static info support, which becomes interactive, if update_edited_overlay() is used all_tags(include_metadata) // returns tags, plus optional metadata like doc strings and highlighting info tags_in_file(f) // interactive editing extensions update_edited_overlay(f, start_line, start_col, end_line, end_col, new_content) highlight_info(f, start_line, end_line) completions_at(f, line, col) You could then run this in the background, for big IDEs, or just run it ahead of time, extract tags, and write an index / highlighting file, for simpler editors. What's more, it would be a framework that many other languages could adopt. -- Lee ___ 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] RFC: Future of the Build System
I agree. If you take this path, use Cmake or scons. - Gaetan 2014/1/15 Robert Knight robertkni...@gmail.com Probably 100 lines of python, plus templates; a bit more to make it highly usable. Not sure what the equivalent would be in Rust code, as I'm still fairly new to it. Maybe the initial version - then you add logic to deal with different versions of Xcode/Visual Studio etc, then some more logic to find different packages that rust requires to build on a multitude of systems etc. etc. Sometimes you can get away writing something new and simple that just deals with your use case (building Rust here). The problem is if you end up with lots of feature creep re-discovering all the knowledge that is encoded in existing tools - eg. the many modules for config checks, locating packages etc. that come with CMake, automake, SCons etc. By all means, have a go at writing that initial version and see how well it serves you - but be prepared to switch if it looks like you are re-inventing something that already exists. On 21 October 2013 12:43, George Makrydakis irrequie...@gmail.com wrote: This is why I am reserving commentation right now and have been consistently asking about Rust providing a build system in all other emails. Can the other commenters refocus with the rest of us back to the original question? Corey Richardson co...@octayn.net wrote: On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden leebr...@gmail.com wrote: Another point is that we don't really need a massively complicated build system right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. ___ 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] RFC: Future of the Build System
To answer to this RFC, I don't see what will be improved if cmake where used. The makefile macro may be rewritten in CMakeList.txt stuff, but this will still generate makefiles and thus don't solve the compilation time. I'm curious about ninjahttp://martine.github.io/ninja/manual.html#_philosophical_overview, it is its promise to provide a simple, clean, super-fast Make. It has been made to replace the old Makefiles and even scons files to build google chrome. And moreover, it follows the UNIX principles: do one thing but do it well. It's adviced to use a meta build sytem like CMake or gyp. Does anyone has ever used ninja intensively? And then, a rust meta build program could be written to replace this metabuilder (i.e. cmake), without having to rewrite the complete ninja layer (I suppose there will be some ninja module to write to answer some issues). And see if at the end the ninja build layer can be replaced completely by a rust one. Arg, as I unroll my idea i see that it is exactly the proposal 3 in the original email... For me, poll will not give the necessary feedback about any system, merely personal point of view. Maybe it's a good start. A good deliverable should be to generate some small reports with presentation, pro, cons... the most applicable to the compilation of the rust compiler and then vote can happen. I've opened a doodle here http://doodle.com/3ngkb9ms9gt2qrap. - Gaetan 2014/1/15 George Makrydakis irrequie...@gmail.com As an interim solution, any proven build system will do regardless of preference. Given the current status quo of Rust's evolving condition, the choice should weigh on the side compatible with what the core developers use since they build way too often. Simplify the build process by reducing number of tools required, going towards a single tool if possible. That would make the option of rusting an alternative, future solution far easier to adopt if that would still be an option. Should a poll be made instead of these threads? Lee Braiden leebr...@gmail.com wrote: On 14/01/14 23:43, Corey Richardson wrote: This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. I think it naturally progressed, because some people wanted to discuss a more generic solution. But fair enough... if the only goal is to build rust, I've very little preference, except to say: Please choose something cross-platform that's as standard as possible, and leads to builds as simple as make or configure make or something along those lines. At the outside, CMake's cmake -G 'Unix Makefiles' etc. is tolerable (for me), in the name of supporting IDE users. ___ 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] sticker
Just came accross this good presentation: http://www.youtube.com/watch?v=gfCtbGiHcg0 A question poped into my head: where could I find rust stickers ? - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
this looks like POM :)
I always dreamt of writing a proper build system with such high level
structure, deal with project dependencies, but that is way more complex
than that.
if a project in rust start with this matter, I volunteer to participate to
it.
-
Gaetan
2014/1/14 Lee Braiden leebr...@gmail.com
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the end
what
the official stance should be. There is no valid reason other than lack
of
manpower and / or language immaturity for having to depend on ruby,
python,
autotools, cmake or whatever else in order to build rust software.
There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identicalsnip
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performancesnip
This e-mail sums up my feelings to a T, and it's why I'm conflicted about
the whole matter.
The more people talk about different build systems and how we can't choose
one yet, the more I agree.
So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice. That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.
So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any tool can use. Perhaps something like this?
[
project: {
name: someproject,
brief-description: some description,
limited-description: [
Para-one.,
Para-two.,
Para-three.
],
web: http://buggysoft.com;,
screenshots:{
screenshot one: {
uri: http://www.buggypics.com/massivebug.png;,
alt-text: Features massive bugs,
},
},
bug-tickets: http://overloaded-cloud-system.buggysoft.com;,
authors: {
author1: {
email:auth...@someplace.com,
web: http://someplace.com;,
},
},
copyright: {
license-file:docs/LICENSE.TXT,
license-flags:SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE,
},
build-info: {
build-type:library,
target: libx.so
source-files: [ src/*.rs, somedir/a_file.rs ],
},
developer-support-info: {
rust-ide-doc-file: docs/libx.rustapi,
rust-ide-completion-file: docs/libx.rusttags,
},
dependencies: {
rust-projects: {
someotherproject: {# from that projects
project - name entry
# following fields are optional; any specified
filter the list
# the list of suitable candidates.
min-version: 0.1,
max-version: 0.1,
gitrepo: http://somehub.com/someuser/
someotherproject/,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri: http://someotherproject.com/
somepath-${version}.tgz,
distro-version-ok:true
}
},
external-libs: {
libssl:{
min-version: 0.1,
max-version: 0.1,
gitrepo: http://somehub.com/someuser/
someotherproject/,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri: http://someotherproject.com/
somepath-${version}.tgz
distro-version-ok:true,
}
},
}
}
]
--
Lee
___
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] RFC: Future of the Build System
i read the ninja documentation, and this integrates well with cmake, and do the majority of the graph stuff required to compile file. i kind of like it. and i wonder why rust-pkg cannot be extended, for simple project to generate ninja files... - Gaetan 2014/1/15 Lee Braiden leebr...@gmail.com On 14/01/14 22:51, Gaetan wrote: you cannot stick build environment with one system. apt is now on every system, you cannot use it under windows or mac. I think you're misunderstanding me. I don't favor debian in any way. I would like debian people (and windows people, and mac people, and BSD people, and cloud deployment people, etc.) to be able to use Rust packages in whatever why they choose, though. and apt source simply checkout the source zip from repository, this is not a proper build system. This is getting off topic, but no, apt-get source builds source code that's already been patched with package information. It's exactly how debian builds its packages for general use. package management is one job and build is another one. you will use another package management on another system, while you expect to use the same build system on another system. That's true IF your package manager only supports third-party binaries. However, if your package manager includes some build process, as most emphatically DO, then I believe that's incorrect. However, I understand that you're saying we shouldn't rely on particular package managers. That is NOT my intention -- just the opposite :) in my experience, i ended up quite often with some bash script for unix like systems that generates some makefiles or trigs cmake/cpack, visual studio or eclipse projects for windows. the only portable build system i used was cmake, which exists under windows mac and unit, with ctest and cpack, even if there are quite limited. And there were a lot of if windows... Yes, this is what I'm saying :) But, i tend to NOT recommend cmake if the final goal is to be integrated into systems like debian. The final goal would be to allow every distro, every operating system, every continuous integration system, every shell script, every cloud image builder, every mobile phone developer, and custom OS writer, do work with Rust packages in whatever way suits them best. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Call for central external packages repository
Sounds great. Can you replace the last commit msg by project description? I think this much more relevant. - Gaetan 2014/1/13 Huon Wilson dbau...@gmail.com On 13/01/14 22:09, Hans Jørgen Hoel wrote: Hi, Regarding rust-ci, I'm about to deploy some changes for it sometime in the next few days. Changes will include: - project editing enabled (including removal of projects :)) - possibility for adding categories to projects and a category based index - documentation upload from Travis CI builds (by adding two lines to the .travis.yml) Woah, woah. This sounds awesome. Huon I've also started working on search which would index project descriptions, uploaded documentation and sources. Source for the webapp will be available on GitHub soon if anyone is interested in collaborating. Regards, Hans Jørgen On 13 January 2014 11:43, Gaetan gae...@xeberon.net wrote: Hi I know this question has been debated, however I'd like to highly recommend to give a clean infrastructure to register, list, search and describe external libraries developed by everyone. For instance, how do I know which http server lib should I use for rust 0.9? This mailing list is quite good for announcing new package, but not for find existing project that might have solved a given problem before me. rust-ci This is the main candidate for this job, however I find it quite difficult to find which project does what. It miss a one line project description column. Its main purpose seem to watch for this set of projects still compile against the master git branch, but there are other lib that are not listed here. I would recommend a central repository web site, working like pypi or other community based repo, that would stimulate user contribution. Such central repository would provide the following features: - hierarchical project organisation (look at herehttps://pypi.python.org/pypi?%3Aaction=browse ) - provide clean forms to submit, review, publish, vote project - clealy display which version of rust compiler (0.8, 0.9, master,...) this lib is validated. For master, this would be linked to rust-ci. I also like the idea of having automatic rust-ci validation for rust 0.8, 0.9,... Maybe with several level of validation: compile validated, peer/administrator validated, recommended,... - good search form. This is how users look for a given project - popular project. I tend to choose a project over its popularity. The more popular a project is, or the more downloads count a lib have, the more I think it will be actively maintained or more stable than the others. - clear project dependency listing - be promoted by rust homepage (repo.rust.org? rustpkg.rust.org,...?), so any lambda user can easy find it At first sight, I think we could just extending rust-ci to do this, reoriented for package listing for a given rust version, by adding new pages package index for 0.9 with just a project name column (rust-http and not chris-morgan/rust-httphttps://github.com/chris-morgan/rust-http) and a description column (extracted from github project description?.. this also force to have to be on github for any project?). And what about tarball or non github project? What do you think about this idea? I am interested on working on this matter, but would like to have your opinion on it. Thanks - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing listRust-dev@mozilla.orghttps://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] RFC: Future of the Build System
what about using a well known build system as a transition to a custom, rust-written build tool? If this is not planned in rust roadmap, I can't see how this will work. For me it's the same old dilemna: write my tool or use an existing one? Same for doc... should we use sphinx or write a customized tool? - Gaetan 2014/1/11 George Makrydakis irrequie...@gmail.com There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. ___ 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] RFC: Future of the Build System
I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. Le 10 janv. 2014 08:43, Carter Schonwald carter.schonw...@gmail.com a écrit : If the in rust approach is chosen, I warmly recommend checking out some of the design ideas in Shake. Shake has a pretty nice design that allows for dynamic build deps (in make systems the way around that is to use make to make your make files), and a few other neat ideas, including but not limited to playing nice with ninja files (which I believe cmake can generate too). http://community.haskell.org/~ndm/shake/ http://hackage.haskell.org/package/shake On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. G. Corey Richardson co...@octayn.net wrote: Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) [...] 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) [...] ___ 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] RFC: Future of the Build System
See this page that compares scons to other build system: http://www.scons.org/wiki/SconsVsOtherBuildTools I still personally recommend CMake. One of the major feature is that it is NOT a build system, it a script factory that generates system dependant build file: Makefile for GNU, Visual Studio for Windows, Eclipse projects,... It actually replaces all bash scripts we usually write on large projects to trigger the builds. - Gaetan 2014/1/10 Jan Niklas Hasse jha...@gmail.com Have you heart about waf? http://code.google.com/p/waf/ It only depends on Python so this would not result in another dependency. The python script ( 200 kB) can be included in the repository. I am all for using rustpkg though. And I'm strongly against cmake, because I don't know its language and don't like a build system which doesn't use an already existing one (like scons is using Python). Also cmake still depends on make (or even worse Visual Studio / Xcode). 2014/1/10 Corey Richardson co...@octayn.net Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does anyone have good ideas or opinions on what we should do? Personally I think that 3 is going to be the best option, unless there's some super amazing build system I haven't heard of it. Which is totally possible! [1]: http://www.cmake.org/ [2]: http://gittup.org/tup/ [3]: http://martine.github.io/ninja/ [4]: https://github.com/mozilla/rust/issues/6522 ___ 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] RFC: Future of the Build System
I also agree that the way waf works is quite weird to use, but this is actually how most of the installers works under windows or some on MacOS: the code of the installers is embedded into the distributed package. This violates the debian packaging rules, and I think this will be the same with rust. I however really like this approach. You don't have a huge among of dependencies to setup in order to build your package. This is not a problem on debian where apt does to marveillous job, but on Windows/Mac/generic linux/arm, .. this is a nightmare. One more point in favor of CMake to build rust: you can build android/arm/misc (thanks to Makefile) with the same CMakeList.txt files, or with external module inclusion. I also agree that its syntax used to be quite ugly (the famous if() / else() / endif()), but not so much in the lastest versions... But if you require python for building, scons is the perfect, natural candidate. - Gaetan 2014/1/10 SiegeLord slab...@aim.com On 01/10/2014 06:19 AM, Robert Knight wrote: Hello, CMake does have a few things going for it: One more consideration is that LLVM can be built with CMake afaik, so if we switch to CMake we may be able to drop the autotools dependency, which is a more annoying dependency to fulfill (on Windows) than CMake (I don't know if Rust has other components that require autotools though). Along the same lines, we also require Python for whatever reason, so SCons would be a natural option too (it can't build LLVM though). I'd only use SCons conditional on it accepting a Rust dependency scanner into its source: using its current custom scanner infrastructure is not practical as I found out. As for waf... they and Debian have been having a tiff (e.g. see http://waf-devel.blogspot.com/2012/01/debian.html , https://lists.debian.org/debian-devel/2012/02/msg00207.html ). I would not suggest it based on that. -SL ___ 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] Configuration files library for Rust
I m also interessed in writing a YAML loader/dumper for rust but i m still learning the language... Le 4 janv. 2014 19:00, Flaper87 flape...@gmail.com a écrit : 2014/1/4 Corey Richardson co...@octayn.net oslo.config looks decent. On some projects I've worked on, we started out using INI files but found them severely lacking once we wanted to extend the options. We ended up using libconfig[0], which I think is an excellent library. In multibuilder[1], we use extra::serialize to load a config directly into the struct we'll be using. It's super convenient, but a bit unfortunate in that it's impossible to make a field truly optional (OptionT requires the field to be null, iirc). [0] http://www.hyperrealm.com/libconfig/ [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 I'm also considering to have support for several parsers. It should be pretty simple / straightforward to do so. We could have a default parser based on INI files and then allow people to specify a different parser in case INI files are not what they want to use. I'll dive into libconfig and pick things from there as well. Also, I agree INI files could be a bit limited, which is why we ended up having our own INI parser in oslo.config. Thoughts? FF On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 flape...@gmail.com wrote: Hi Guys, 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. Since I've some experience on this area, I thought about doing some work on it for Rust. My current plan is to do something along the lines of oslo.config[0] - which I've been contributing to - and take advantage of the existing getopt module, just as we do in oslo.config. The config file format parsed by oslo.config follows the INI[1] files format but with some changes to support list options and other types. One of the advantages of this library is that the config options registration is explicit and simple. However, before starting to work on this, I'd like to know what folks on this list think about the library, if there's been some work on this area that I'm not aware of, what the preferences are, etc. Cheers, FF [0] https://github.com/openstack/oslo.config [1] http://en.wikipedia.org/wiki/INI_file -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ 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] Configuration files library for Rust
I m interessed on having your feedback on json and yaml vs toml for instance. Le 4 janv. 2014 19:28, Paul Nathan pnat...@vandals.uidaho.edu a écrit : On 1/4/14 10:00 AM, Michael Neumann wrote: Am 04.01.2014 18:38, schrieb Corey Richardson: oslo.config looks decent. On some projects I've worked on, we started out using INI files but found them severely lacking once we wanted to extend the options. We ended up using libconfig[0], which I think is an excellent library. In multibuilder[1], we use extra::serialize to load a config directly into the struct we'll be using. It's super convenient, but a bit unfortunate in that it's impossible to make a field truly optional (OptionT requires the field to be null, iirc). [0] http://www.hyperrealm.com/libconfig/ [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 There is also TOML [1], an extended version of the INI config file format, which is used by a variety of languages. [1]: https://github.com/mojombo/toml Regards, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev . I've used YAML, JSON, and INI extensively for configuration, and I confess that each have their problems. I agree that TOML is an excellent idea (I wrote the Common Lisp TOML parser). I just don't know off-hand how widely its been picked up in the past year. -- Regards, Paul ___ 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] Configuration files library for Rust
Thanks for your answer. I think having reference parsers for majors format is a top feature for the rust standard lib. Json is pretty standard in web world, and yaml is pretty simple replacement for XML but lack schema standard. So if rust provides Json, yaml, ini, toml and why not other config storage/exchange standards, that will surely attack many developpers, but i recommend to have a certain homogeneity in the API. I ve used yaml for quite long time, and indeed indentation can be an issue, but that the same with Python code I am not fan with indentation meaning nesting, but yaml is much simpler for me to use than Json. Le 4 janv. 2014 21:59, Chris Molozian ch...@cmoz.me a écrit : I second the sysctl syntax it’s very easy to grep through configuration files in this format. The “key” prefix contains the context for the information which is useful. i.e. “riak_kv.anti_entropy_leveldb_opts.write_buffer_size” Riak, a distributed KV dynamo store has recently been moving to the sysctl format from the traditional Erlang `app.config` “format. Cheers. -- Chris Molozian Software Engineer On 4 January 2014 at 20:41:59, Christopher Meiklejohn ( christopher.meiklej...@gmail.com) wrote: On Jan 4, 2014, at 3:39 PM, Tony Arcieri basc...@gmail.com wrote: On Sat, Jan 4, 2014 at 12:35 PM, Daniel Micay danielmi...@gmail.comwrote: I don't buy that. A text editor should be more than capable enough to stop you from slipping in tabs. If there's a separate untested configuration for production then you have a problem. This isn't just a single offhand incident. It's something I've seen a pattern of happening dozens of times over the course of my career. It's happened to me personally, and I've seen it happen to others. Having separate configuration sections for different environments is a rather common convention in the Rails world. Is it a bad idea? Offhand I can't say: what would you replace it with? Why not something that looks like sysctl [1] syntax? http://www5.us.freebsd.org/doc/handbook/configtuning-sysctl.html - Chris ___ 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 -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] on quality success
I also agree this thread doesn't add grist to the mill. Let's cut it. - Gaetan 2014/1/2 Palmer Cox palmer...@gmail.com Everyone is entitled to their own opinions. However, those opinions should be expressed in a polite manner. Phrases such as Choice he (since its mostly men) and mentally masturbate do not seem to foster a welcoming, inclusive environment. Quoting from https://github.com/mozilla/rust/wiki/Note-development-policy#conduct: * We are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, disability, ethnicity, religion, or similar personal characteristic Thanks, -Palmer Cox On Tue, Dec 31, 2013 at 6:56 AM, spir denis.s...@gmail.com wrote: Holà! [This is a rather personal and involved post. Press del if you feel like it...] [also, it is long] [copy to rust-dev mailing list: actually the post is inspired by a thread there Thoughts on the Rust Roadmap] There is a point obvious to me; apparently most people including many language designers don't share it, or act as if they did not: a language should be successful iff it is of high quality A kind of symmetric statement also holds; let us hope low quality languages have no success! There are various reasons to hope this, the most stupid beeing that successful languages influence others, present future. This is in my view a symptom of our civilisation's funny spirit (read: madness), and related to the actual points I intend to state (if, for once, I manage to express my thought). Apparently, many language designers proceed more or less the following way: there are a few key points (for them) they consider mis-designed or missing or wrong in some way in existing languages (not all the same for every language). Thus, they want to make a language that repairs these points, all together. Then, certainly in fear that too many changes may repel potential adopters of their language, in hope to maximise its chances of success *despite* it breaking habits on the key points more important to them, they won't change anything else, or only the bare minimum they can. They want instead to remain as mainstream as possible on everything else. [4] I consider this spirit bad; I mean, very bad. This is the way basic design errors propagate from successful languages to others, for instance. [1] Apparently, it takes a great dose of courage to break any existing practice in a _new_ language: tell me why, I do not understand. Note that I am here talking of wrong design points in the opinion of a given language designer. Choices he (since it's mostly men) would not do if programming were a new field, open to all explorations. (There are indeed loads of subjective or ideological design points; see also [1] [3]) However, while programming is not a new field anymore, it is indeed open to all explorations, for you, for me, if you or me wants it. Nothing blocks us but our own bloackages, our own fears, and, probably, wrong rationales, perhaps non-fully-conscious ones. Deciding to reuse wrong, but mainstream, design decisions in one's own language is deciding to intentionally make it of lower quality. !!! Funny (read: mad), isn't it? It is thus also intentionally deciding to make it not worth success. This, apparently, to make its actual chances of success higher. (Isn't our culture funny?) Then, why does one _actually_ make a new language? For the joy of making something good? To contribute to a better world, since languages and programming are a common good? [2] For the joy of offering something of as high a quality as humanly possible? Else, why? For fame, honour, status, money, power? To mentally masturbate on the idea of having made something sucessful (sic!)? We are not in need of yet another language trying, or pretending, to improve on a handful of disparate points, leaving all the rest as is, meaning in bad state. And, as an example, we are not in need of yet another failed trial for a successor to C as major low-level lang. Differences, thought of by their designer as significant quality improvements, are the *reasons* for programmers to adopt a new language. There are the _only_ (good) reasons to do so. Thinking that programmers may adopt a new language _despite_ its differences is thinking backwards; this, in addition to preventing oneself from working for the common good; by fear, probably; fear of truely thinking by oneself and/or of making one's true thinking public truely. (I can understand that, however: I often do not disclose my thinking by fear of the terrible level of violence, in my view, present in the programming community [hum!], and among geeks in general. This, rather than sharing and mutual help and cooperation, for the common wealth. Our civilisation... again.) I have recently decided to adopt possible differences even if i am not that convinced of their betterness; to give
Re: [rust-dev] Using CMake with Rust
I used cmake for years and was quite happy with it, so a support of cmake is welcomed. I recommend have it officially integrated into rust, along with some other popular toolsets (scon, bare makefiles, visual studio,...). Even if VS can derive from cmake. This is a strategic added value to have it provided by the language. I also would like to add I find this complementary to rust-pkg. For simple project, this latter might do the job, but for very complex projects, a full featured build system might be used, so let's have it seamlessly integrated into rust. - Gaetan 2014/1/2 SiegeLord slab...@aim.com On 01/02/2014 12:05 AM, György Andrasek wrote: The proper way to support a language in CMake is outlined in `Modules/CMakeAddNewLanguage.txt`: I was guided away from that method by this email: http://www.cmake.org/ pipermail/cmake/2011-March/043444.html . My approach is amenable to generating files for alternative build systems, like ninja. If you are aware that that email is incorrect, I'm glad to be corrected. Independently of that email, I have looked into doing it that way, but I found that it just did not mesh with the Rust compilation model, and I saw no clear way to using the information given by 'rustc --dep-info' to inform the build system. Additionally, my macros allow an easy way of doing documentation generation, which that method doesn't clearly allow. I'll be glad to be corrected on all those points though. -SL ___ 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] Let’s avoid having both foo() and foo_opt()
That is pretty elegant.
Le 22 déc. 2013 16:47, Gábor Lehel glaebho...@gmail.com a écrit :
Using `match` works well enough, but if there's demand for a refutable
`let` which is lighter-weight, what about:
let Some(result) = from_utf8(some_bytes) else fail!();
In other words, if the `let` pattern is refutable, you have to provide
something `else` with return type `!` as the alternative for when the `let`
fails to match.
(I could imagine that being generalized to any number of `else`s of which
only the last returns `!` (i.o.w. never returns), for example
let Some(result) = from_utf8(some_bytes) else
from_utf8(some_other_bytes) else fail!();
and/or to allowing anything `else` which always matches, e.g.
let Some(result) = from_utf8(some_bytes) else Some(default);
of which anything that returns `!` would be only a special case. But
these have progressively diminishing returns, and I'm merely mentioning,
not endorsing them.)
On Tue, Dec 17, 2013 at 9:11 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 17, 2013, at 11:37 AM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
Hi,
Am 17.12.2013 um 20:10 schrieb Corey Richardson co...@octayn.net:
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
Hi,
Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com:
I have no idea if it would be feasible in the standard library, but
wouldn't the ideal solution be having one function (e.g. from_utf8()) that
could return two possible values, a bare result and an Option? Letting the
compiler decide which version to use based on type inference like this:
let result: ~str = from_utf8(...);
let result: Option~str = from_utf8(...);
Assuming both of them are passed invalid UTF8, then the first version
would fail, but the second version would just return None.
We already have pattern matching in `let` (the LHS is a pattern), but
it's only for irrefutable patterns. IOW, `let` can never fail, and
that's a very very useful property IMO.
oh ok I haven’t kept up on the syntax then. Given the utility of
destructuring bind for error handling, wouldn't it make sense to have a
variant of let that can fail?
Now syntax is a matter of practicality and taste but spontaneously this
comes to mind:
let opt Some(~result) = from_utf8(..)
comes to mind.
You can do it with a bit more verbosity, which I think is perfectly fine
as it makes failure much more obvious.
let result = match from_utf8(..) {
Some(~result) = result,
_ = fail!(b0rk b0rk b0rk)
};
Of course, in this particular example, you'd probably just write
let result = from_utf8(..).unwrap();
but the longer match form will work for other enums.
-Kevin
___
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
[rust-dev] Fwd: Re: Let’s avoid having both foo() and foo_opt()
I like this syntax:
let Some(result) = from_utf8(some_bytes) else defaultValue;
Or
Let result = from_utf8 (some_bytes) else defaultValue
If implicit conversion could be properly checked it would be so cool !
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
Using `match` works well enough, but if there's demand for a refutable
`let` which is lighter-weight, what about:
let Some(result) = from_utf8(some_bytes) else fail!();
This is a nice idea. At first I thought it wouldn’t work with `if` but
in expressions `if` requires `else` so the grammar wouldn’t be ambiguous:
let Some(result) = if cond { .. } else { … } else fail();
In other words, if the `let` pattern is refutable, you have to provide
something `else` with return type `!` as the alternative for when the `let`
fails to match.
Shouldn't the return be the same for all expressions? This would allow:
let Some(result) = from_utf8(some_bytes) else Some(defaultValue);
Stefan.
___
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] December 17th San Francisco Bay Area Meetup
Thanks! I fully agree for all the anti markdown part! sphinx/RST is much more powerful for generating the documentation. - Gaetan 2013/12/20 Erick Tryzelaar erick.tryzel...@gmail.com Good evening everyone! We had a great meetup earlier this week, and we were fortunate to have Air Mozilla record the presentations in case any of you were not able to attend: https://air.mozilla.org/rust-meetup-december-2013/. Also, you can find the slides of all the presentations here: Steve: http://steveklabnik.github.io/rust_documentation/#/ Chris: http://chrismorgan.info/blog/rust-docs-vision-presentation.html Alex: https://docs.google.com/presentation/d/1oB3hwBByGNcgst-X0SSmRyu-uMfayeySNAJdkwwtB9Q/edit?usp=sharing Luqman didn't use slides, but he did step through his Mincraft Chat Client, which you can find here: https://github.com/luqmana/mcchat Thanks everyone for participating! -Erick On Thu, Dec 5, 2013 at 7:27 PM, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Good evening Rusties, I'm happy to announce the next Bay Area Rust meetup on December 17th in San Francisco. Mozilla is graciously hosting us again. We've got a couple short talks lined up: • Luqman Aden will talk about using Rust to make a Minecraft Chat Clienthttps://github.com/luqmana/mcchat . • Alex Crichton will talk about Channels and their performance. • Brian Anderson will talk about *something*. • And if he's able to get it to a presentable state, Kevin Ballard will talk about his safe Lua Bindings. It'll start at 7:00pm and go until 10:00pm. If you would like to attend, please sign up here: http://www.meetup.com/Rust-Bay-Area/events/153010612/ We also might have some room for more other talks, so if you would like to present something at this meetup, or a future one, please let me know. I hope you can make it! -Erick ___ 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] [whoami] crate, package and module confused me!
I am in favor of replacing the mod keyword by crate. #[package_id = whoami]; #[package_type = lib]; ... use crate whoamiextern but I wouldn't understand why the 'mod' keyword would stay - Gaetan 2013/12/18 Liigo Zhuang com.li...@gmail.com `use crate foo; ` looks good to me. i always think it should be optional. rustc can deduce which crate will be used, from use mods lines, in most situations. 2013/12/18 Brian Anderson bander...@mozilla.com We discussed this some in the meeting today: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-12-17 On 12/16/2013 06:41 PM, Liigo Zhuang wrote: 2013/12/16 Brian Anderson bander...@mozilla.com My feeling is that it is a crate, since that's the name we've historically used. There's already been agreement to remove extern mod in favor of crate. IMO, package is used in several languages, maybe it's much familiar and friendly to rust newbies: ``` package newpkg; // pkgid is newpkg, compile to dynamic library (.so) package main; // pkgid main means compile to executable program (.exe) static package newpkg; // pkgid is newpkg, compile to static library extern package newpkg; // or … extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` But I'm OK if crate is used here. Liigo, 2013-12-17. -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ 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] [whoami] crate, package and module confused me!
I prefere keeping crate and package, turn crate_type to package_typa, and change mod keyword to crate. But I don't know what rust devevelopers think #[pkgid = whoami]; #[package_type = lib]; ... extern crate whoami - Gaetan 2013/12/15 Liigo Zhuang com.li...@gmail.com Rust compiler compiles crates, rustpkg manages packages. When develope a library for rust, I write these code in lib.rs: ``` #[pkgid = whoami]; #[crate_type = lib]; ``` Note, I set its package id, and set its crate type, and it is compiled to an .so library. Now please tell me, what it is? A package? A crate? or just a library? If it's a package, why I set its crate type? If it's a crate, why I set its package id? Confusing. And when use it (whoami), I must write the code: ``` extern mod whoami; ``` Now was it transmuted to a module?? If it's a module, why I haven't set its module id and module type? If it's not a module, why not use `extern package whoami` or `extern crate whoami` here? Full of confusion. Can you please tell me WHAT it really is? Thank you. ~~ The following is my answer and my solution: We remove crate everywhere. And the answer is obvious: it is a package. Package is a compile unit, it contains a root module (with the same name as pkgid), and module contains sub-modules. A package may be compiled to dynamic library, static library or executable program. package is a new keyword. When define a package, we first write one of these lines: ``` package newpkg; /// pkgid is newpkg, compile to dynamic library (.so) package main; /// pkgid main means compile to executable program (.exe) static package newpkg; /// pkgid is newpkg, compile to static library ``` It replaced the #[pkgid] and #[crate_type], the doc-comments replaced the #[desc]. When declare using the package, we write code: ``` extern package newpkg; // or … extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` The `extern package newpkg;` should be optional, because, when we write: ``` use newpkg::a::b; ``` … rust compiler always knows it's using extern package `newpkg`. (If name conflicts with local module, compiler should emit an error.) Liigo, 2013-12-15. ___ 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] Rust crates and the module system
Libstuff is a library, in the system semantic (linux, same for windows). It may contain one crate, it should be still named after what it is in the system, but it is not properly speaking part of the rust semantic. However alone it is almost useless, you need extra data to.locate, index, install, uninstall it,... and that what a package should be. Rust as two level: crates and package. Even if a concurrent packaging system rustbetterpkg can appear and do the same job differently without changing the rust language. Le 14 déc. 2013 05:28, Liigo Zhuang com.li...@gmail.com a écrit : 2013/12/14 Corey Richardson co...@octayn.net Packages don't really exist as a concept at all. Supposedly `rustpkg` deals with packages but in reality, it just deals with crates. And they're certainly not part of the module system. 2013/12/14 György Andrasek jur...@gmail.com On 12/14/2013 02:14 AM, Liigo Zhuang wrote: What is the distinction of package and crate in Rust? Crate is the compilation unit. Package is what you say it is, the Rust manual does not mention that word. There is an official tool called rustpkg, and there is a attribute call pkgid, so you cann't just easily saying there is no package in rust. If no package, why not using rustcrate and crateid for consistency? (I do not think 'crate' is a good name, other languages tend to call it 'package' or 'library'.) On Fri, Dec 13, 2013 at 8:14 PM, Liigo Zhuang com.li...@gmail.com wrote: What is the distinction of package and crate in Rust? 2013/12/14 Patrick Walton pcwal...@mozilla.com On 12/13/13 4:56 PM, Liigo Zhuang wrote: package and module, we only need one. Most other language only have one. The more, the more complicate. libstd.so: What we call it? library package crate?? other language usually call it library. std::io::fs: We call it module, other language usually call it package or module. So, whatever we call it, package and module, we only need ONE of them, and let another gone. .NET has a two-level distinction: assembly and namespace. C++ has a three-level distinction in practice—namespace, library/executable, and translation unit—although C++'s is somewhat different. OCaml has a two-level distinction: library and module. D has a two-level distinction as far as I can tell: library and module. Racket has a two-level distinction as far as I can tell: package and module. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by Liigo, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ 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] Rust crates and the module system
I actually really like the way python modules are organised, it's really
helpfulfor developping, really easy for unit testing just some modules. If
it is that way by default, and allow different structure by adding some
boilderplate, that could be really interesting
-
Gaetan
2013/12/13 Felix S. Klock II pnkfe...@mozilla.com
On 13/12/2013 12:53, spir wrote:
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the opposite):
* 1 module = 1 file of code
* 1 package = 1 dir
This may be limiting at times, possibility one may want multi-module
files and multi-file modules.
Yes, one may indeed want those things. In particular, *I* want
multi-module files.
I do not want to move towards a Java-style approach where the package
nesting structure needs to match the file/directory nesting structure.
Being able to declare nested modules within a file is very useful for
flexible namespace control.
I like our current support for nesting modules in files, and breaking them
out into separate files as one wants.
But then again, I also think that the current approach of { `extern
mod`... `use`... `mod`... } is pretty understandable once you, well,
understand it. My main complaint has been about the slightly
context-dependent interpretation of paths [1], but that's pretty minor. So
perhaps I have the wrong point-of-view for interpreting these suggestions
for change.
Cheers,
-Felix
[1] https://github.com/mozilla/rust/issues/10910
On 13/12/2013 12:53, spir wrote:
On 12/13/2013 11:43 AM, Diggory Hardy wrote:
What would you do?
Have no structure (no mod)? Or automatically create it from the file
structure?
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the opposite):
* 1 module = 1 file of code
* 1 package = 1 dir
This may be limiting at times, possibility one may want multi-module
files and multi-file modules. But this forms a good, simple base (anyway,
we have mini maxi modules code files, whatever the logical physical
organisations). Another point is that very often we have package (I mean
crate ;-) sub-dirs which are not packages themselves. Then, as usual, we'd
have a special code file representing a package at its top dir (the same
name as the package, or a magic name like 'main').
Then, module sharing is code file sharing, and package management is dir
management (trivially .zip-ed or .tar.gz-ed, and then the name package is
here for something).
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.com
___
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] Interface around SQL databases
I agree python dbapi is pretty simple to use due to the dynamic nature of types in python. I like this rust postgre binding, I can't see why it cannot be extended to support mysql? Actually, my main reference is sqlalchemy but it's a step much higher in term of abstraction of the DB. - Gaetan 2013/12/11 Corey Richardson co...@octayn.net Python has the advantage of dynamic typing, and Go runtime type assertions and variadics. Their interfaces probably aren't /too/ good for inspiration, especially Python's. See rust-postgres (https://github.com/sfackler/rust-postgres) for an existing DB binding. I think it's fairly idiomatic and any DB API should draw inspiration from it. It leverages trait objects, though it's unclear that that can be generic. Personally I've never really been a fan of generic SQL APIs. Unless they leverage intense amounts of magic (Entity Framework, SQLAlchemy), I find they end up being crippled (luasql) or fairly uses (python's dbapi). Maybe that's just me. On Wed, Dec 11, 2013 at 9:24 AM, 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 - Gaetan 2013/12/11 John Mija jon...@proinbox.com Before of release 1.0, it would be very good if it's added to the package standard a generic interface to be implemented by the packages of SQL drivers. As example, see packages database/sql and database/sql/driver in the Go's library: http://golang.org/pkg/database/ ___ 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] Let’s avoid having both foo() and foo_opt()
let result: ~str = from_utf8(...);
let result: Option~str = from_utf8(...);
That was what I called implicit unwrap. I however recommend ``let result
= from_utf8(...)`` to be the unwrapped version (ie, result is ~str)
Do you think it is possible to add this syntaxic sugar?
fn any_function() - Result~str
{
...
}
// When called :
let s = any_function(); // unwrap() is automatically called, s is a ~str
let res = any_function?(); // unwrap is not called, res is a Result~str
let res2: Result~str = any_function(); // unwrap is not called, res is a
Result~str
if res.is_ok() {
let s2 = res.unwrap()
}
Or maybe a simpler version, but the semantic is reversed, where a?() means
a().unwrap():
let res = any_function(); // unwrap is not called, res is a Result~str
let s = any_function?(); // unwrap() is automatically called, s is a ~str
-
Gaetan
2013/12/9 Simon Sapin simon.sa...@exyr.org
On 09/12/2013 15:53, Damien Radtke wrote:
I have no idea if it would be feasible in the standard library, but
wouldn't the ideal solution be having one function (e.g. from_utf8())
that could return two possible values, a bare result and an Option?
Letting the compiler decide which version to use based on type inference
like this:
let result: ~str = from_utf8(...);
let result: Option~str = from_utf8(...);
Assuming both of them are passed invalid UTF8, then the first version
would fail, but the second version would just return None.
Again, I don't know if it's possible given the current implementation,
but I do think it would be helpful to have a picture of the ideal, and
then decide on whatever solution comes closest.
It is possible to have a generic return value, see for example the
.collect() method of iterators.
https://github.com/mozilla/rust/blob/4e0cb316fc980f00e1b74f3fdb7a84
2b540be280/src/libstd/iter.rs#L447
But it involves creating a trait, and implementing it for every supported
type. IMO it’s a lot more involved than what we would want for every
operation that may fail on invalid input.
As a side note, even if the standard library sticks with two variants
for each option function, I would prefer the default one return an
Option and have the variant fail on invalid input. Task failure at
runtime is a nastier surprise than an invalid type error at compile
time, especially for new users who aren't entirely sure of the difference.
--
Simon Sapin
___
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] Let’s avoid having both foo() and foo_opt()
What do you think about implicit unwrap? I don't know if this could be done but I find it pretty elegant. It's a design choice. For me all API should follow the same pattern, not some returning bare result without failure case, or return a boolean and modify the content of a pointer, or use Result/Option. Most of function look like thing - function definition - check inputs are correct - process with inputs - return a value Most of std/extra methods currently look like: 1 function def 2 ... .unwrap()...unwrap() 3 continue to unwrap(), unwrap() 4 return Ok(...) or Err(..) or return Option while unwrap in part 2 may have sense (check if inputs are correct), they don't have in the third part of the fn. What I really advise is to go to a solution where the developer will avoid each time to call unwrap/get, without checking for the return state because it cost too much. When you call a system api you check for the result because it has great chance to fail, but when you know what you have in input, you call unwrap() without taking care of the failure cases, and if a failure occurs, you can expect things to be in suffisant bad shape to let the task completely fails. Maybe split the methods into two categories: API calls that may fails and return a Result, and obvious convert methods that has no sens to fails once the input has been properly check, so doesn't use Result. But at the end of this discussion, I also strongly advise to write the solution down in a reference page on the wiki, having the current state of the art for this matter is extremely important, because the source code has different design choices, with this page everyone will know what is the current best pratice for such function calls. PS: I really like the ? solution, where func?() returns a Result and func() return the bare result, I find it in the same spirit than fmt!, that makes the language special but in a sexy way :) - Gaetan 2013/12/7 spir denis.s...@gmail.com On 12/07/2013 10:53 AM, Simon Sapin wrote: On 07/12/2013 01:07, spir 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 This is interesting, but I’d like to discuss what to do in this particular language, Rust that is trying to go to 1.0 and will probably not accept such syntax change :) You are right, indeed! ;-) But the issue exists anyway... dunno about solution. In fact we'd ned to invert the logic: instead of: x = foo() // Option element wrapping possible result x = foo().unwrap() // bare result think: x = foo().option() // Option element wrapping possible result x = foo().direct() // bare result or even x = foo() // bare result 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] Higher-Kinded Types vs C++ Combos
Stack overflow is your friend, you can even vote for the best anwser !
Le 7 déc. 2013 17:43, David Piepgrass qwertie...@gmail.com a écrit :
(Another big reason I like forums over mailing lists, which I forgot to
mention in that other thread, is that I can fix my mistakes!) Typo
correction:
struct ListTrait
{
templatetypename T typedef listT collection;
};
And I'd rephrase my third question:
3. If Rust had C++-style typedefs, would it make sense to argue that we
don't need Higher-Kinded Types, we can just use typedefs for everything?
In case people are finding the Combo concept hard to follow, I will offer
GiST (http://en.wikipedia.org/wiki/GiST) as a concrete example. A GiST
has a few different parts, each of which can be swapped out to produce
different kinds of trees. When I tried to implement the GiST in C#, I found
that I wanted 8 type parameters on the GiST base class:
- The derived tree type
- The internal node type
- The leaf node type
- The compressed left entry type
- The uncompressed leaf entry type
- The compressed internal entry type
- The uncompressed internal entry type
- The key type (type of data stored in an entry)
This, of course, is utterly impractical when they have to be listed
repeatedly, every time the base class is mentioned. I figured out how to
whittle it down to one parameter on the base class and two elsewhere, but I
had to restructure the code in some unnatural ways, so the readability of
the code was substantially harmed, and there was some performance cost as
well (some interfaces, some virtual methods, more casts.)
Even with one or two type parameters, the names of things were still
unweildy because often the concrete type parameters were themselves
parameterized.
Of course, type parameters are not the only way to do a GiST. It can also
be done by defining everything in terms of interfaces (or in Rust, trait
objects). But this implies that when the different parts of the code
interact, they must use dynamic dispatch. Even worse, although the entries
(leaf/internal, compressed/uncompressed) are small implicitly-copyable data
types (let's say 8 - 32 bytes typically, though I don't have the code
handy), most of the code will be unaware how large or small each entry is,
so the entries would (in C# at least) have to be stored on the heap, rather
than passed around directly as structs (I'm not sure what you'd do in Rust).
Thus, if you want to implement a GiST in C# you get either hard-to-follow
code with sub-optimal performance, or straightforward code with terrible
performance. The third alternative, of course, is to not implement a GiST,
but implement each kind of tree (B+ tree, R-tree, ...) separately. This
requires code duplication and repeated design work, the elimination of
which was the reason GiSTs were invented in the first place.
In Rust, I assume you could use macros to overcome some of the problems
that make a GiST difficult to do in C#. However, I am thinking that if
typedef is in some ways a more powerful concept than HKT, arguably Rust
should support them first or investigate whether they can be generalized to
do what HKTs were meant to do.
On Sat, Dec 7, 2013 at 12:10 AM, David Piepgrass qwertie...@gmail.comwrote:
Rust newb here. I have theoretical questions.
Recently I noticed that Higher-Kinded Types (HKTs) have been mentioned on
the mailing list a lot, but I had no idea what a HKT was, or what it might
be good for. After reading about them a little, they reminded me of C++'s
template template parameters. In C++ you can almost write something like
this:
template template typename class collection
struct Numbers {
collectionint integers;
collectionfloat floats;
};
So then you can write Numbersvector for a structure that contains
vectorT collections, and Numberslist for a structure that contains
listT collections. EXCEPT that it doesn't actually work, because
vectorT has two template parameters (the second one, the allocator, is
normally left at its default). Let's ignore that, though.
So that brings me to my first question: is this what higher-kinded
types means? What is the difference, if any, between HKT and C++ template
templates?
However, as a C++ developer I never actually used a template template
parameter because I didn't know they existed for a long time. So instead I
would have written this, which has the same end-result:
struct VectorTrait
{
templatetypename T
struct collection { typedef vectorT type; };
};
struct ListTrait
{
templatetypename T
struct collection { typedef listT type; };
};
templatetypename Traits
struct Numbers
{
Traits::collectionint::type integers;
Traits::collectionfloat::type floats;
};
// Use NumbersVectorTrait for vectorT, NumbersListTrait for listT.
This is clunkier, but it would have been a bit simpler if C++ supported
templatized typedefs:
struct VectorTrait
{
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
I also find the repeatition of unwrap all over the code being quite nasty Most of the time the result is just unwrapped without taking into account the error case, so i think the usage of Option or Result useless. I think a good solution exits and can make the code more maintainable, and easier to read. There should not have all these unwrap (or get) call for code we know it cannot fails, because the necessary check has been done earlier. 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. Or perhaps allow the propagation of Option/Result. Le 7 déc. 2013 01:03, Daniel Micay danielmi...@gmail.com a écrit : On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox palmer...@gmail.com wrote: Why not use Result instead of Option for these types of things? Result is already defined to be able to return error codes using Err. The only way to indicate an error when returning an Option is to return None which doesn't allow for that. Also, IMO, None doesn't necessarily mean error to me. Lets say we have a function defined as: fn do_something(value: Option~str); It seems like it would be much to easy to accidentally write something like: do_something(str::from_utf8(...)) which might result in the error being hidden since do_something might not consider None to be an error input. -Palmer Cox If there's only one reason it could fail, then `Option` is the idiomatic way to report the error case. It's exactly what `Option` is used for. A stack trace can report where the error occurred if you decide to ignore the error case and use `unwrap` (or `get`, if it's renamed). ___ 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] Let’s avoid having both foo() and foo_opt()
Isnt a way for Option to unwrap implicitely when check on error state is not done ? That would make the code less verbose but still allow the dev to check for error if want? Le 7 déc. 2013 01:12, Gaetan gae...@xeberon.net a écrit : I also find the repeatition of unwrap all over the code being quite nasty Most of the time the result is just unwrapped without taking into account the error case, so i think the usage of Option or Result useless. I think a good solution exits and can make the code more maintainable, and easier to read. There should not have all these unwrap (or get) call for code we know it cannot fails, because the necessary check has been done earlier. 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. Or perhaps allow the propagation of Option/Result. Le 7 déc. 2013 01:03, Daniel Micay danielmi...@gmail.com a écrit : On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox palmer...@gmail.com wrote: Why not use Result instead of Option for these types of things? Result is already defined to be able to return error codes using Err. The only way to indicate an error when returning an Option is to return None which doesn't allow for that. Also, IMO, None doesn't necessarily mean error to me. Lets say we have a function defined as: fn do_something(value: Option~str); It seems like it would be much to easy to accidentally write something like: do_something(str::from_utf8(...)) which might result in the error being hidden since do_something might not consider None to be an error input. -Palmer Cox If there's only one reason it could fail, then `Option` is the idiomatic way to report the error case. It's exactly what `Option` is used for. A stack trace can report where the error occurred if you decide to ignore the error case and use `unwrap` (or `get`, if it's renamed). ___ 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] Rust forum
I'm in favor of a properly managed stackoverflow section. stackoverflow does a marvelous job for finding issue someone else has already been confronted before. I never liked forums, search features are always buggy, category are too restrictives, ... mailing list is good for what it does: emails. That's all. - Gaetan 2013/12/3 Tobias Müller trop...@bluewin.ch David Piepgrass qwertie...@gmail.com wrote: Okay, well, I've never liked mailing lists at all, because: 1. In non-digest mode, My inbox gets flooded. 2. In digest mode, it's quite inconvenient to write a reply, having to cut out all the messages that I don't want to reply to and manually edit the subject line. Also, unrelated messages are grouped together while threads are broken apart, making discussions harder to follow. 3. In email I don't get a threaded view. If I go to mailing list archives to see a threaded view, I can't reply. Just use NNTP (gmane.comp.lang.rust.devel on news.gmane.org). Most newsreader support threaded view (Thunderbird does). You can configure the mailing list s.t. mails are not actually delivered to your email address even if you are registered. But looking at your email address you are already using gmane. Tobi ___ 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] Rust forum
Sorry but that is a pretty bad answer. You cannot tell people to change their favorite email client just for rust-dev. You cannot do the same with you client, just because each one will have to set its own set of rules to tag, ... Gmail is a pretty good client, but you have to remember the golden rules of email: email is forgotten once it is read. And you cannot search on emails you havent received... Self hosted forum is good, a good rust management in stack overflow is much better. If you know better sites, why not making some experiment and then vote for the better one. G. Le 3 déc. 2013 21:32, Thad Guidry thadgui...@gmail.com a écrit : Kevin is correct. Where the real issue is that of knowing the capabilities of your particular mail client and maximizing it to gain forum-like features. Many folks use or prefer an online mail client that offers threading, labels, archival search, etc. Which are all the same features of a forum that is proposed. My suggestion would be instead of jumping to a forum... simply learn about or find a more full featured mail client if you can. If you cannot, then perhaps Gmane could benefit you in the same way. Users benefit from the developers list and vice-versa... splitting us apart would not be a wise choice. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ 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] Rust forum
I also agree to split in rust-user for newbee question, but i hope good programmers will go a bit on this ml... Le 3 déc. 2013 21:42, Martin DeMello martindeme...@gmail.com a écrit : On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry thadgui...@gmail.com wrote: Users benefit from the developers list and vice-versa... splitting us apart would not be a wise choice. the only downside is that people are reluctant to ask newbie user questions on a list where people are talking about hacking on the compiler. martin ___ 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] do
if do makes the code more readable or more beautiful, I higly recommend
keeping this sugar syntax. If there are corner cases where do doesn't do
the job, the developer should not use it in these cases.
It's still the same debat, when GIMP had this ugly multi panels system,
developers was saying it is a window manager issue to handle them
correctly. Yet, the GIMP software was a nightmare to use on almost
everybody's desktop. Now they solved with a single window application, it
is much more acceptable.
It will be the same here. If you rely on special feature of the editor to
indent properly. if is was only curly brace, most editor would do
indentation properly, but here you have || and other exotic syntax most
editor doesn't understand until a proper extension is written (which can
take year for some editors).
I personnally will always find much more readable (and maintainable):
do function { someotherFunction() };
than
function(|| someotherFunction());
-
Gaetan
2013/12/2 Alex Bradbury a...@asbradbury.org
On 1 December 2013 03:54, Daniel Micay danielmi...@gmail.com wrote:
I don't understand the point of `do` beyond making zero-parameter
closures look a bit better. If it doesn't even do that, why bother? If
an editor isn't indenting it properly, that's an editor issue. As far
as I can tell, the vim indent file now handles it fine.
I agree, I feel do should be considered for removal - I feel the
amount of sugar it provides is minimal yet it complicates the language
unnecessarily. Supposing that Rust did not have the `do` syntax
already, I tend to think there would be resistance to adding it for
these reasons. Is there currently an issue open regarding the future
of `do`?
Alex
___
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] Placement new and the loss of `new` to keywords
Thanks for this explanation about ~! Can you add a paragraph in the tutorial or manual? Le 30 nov. 2013 08:10, Kevin Ballard ke...@sb.org a écrit : As I said in the IRC channel, the reason why users often don't realize that `~T` is allocation, is not a failure of syntax, but a failure of documentation. The only reason why a user would know that `new Foo` allocates is because they've been exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a keyword, and even more by the fact that the proposed placement new syntax is `new(foo) bar`. This looks exactly like C++, and it goes against the strong precedence we already have of using new() as a static function for types. Path::init(foo) looks extremely wrong to me. Surely there's another syntax we can use for placement new that doesn't involve reserving `new` as a keyword? Here's a few random ideas (where val is the value expression and place is the place expression): ~in(place) val in(place) ~val ~val in place (assuming this isn't somehow ambiguous) ~~val in place (the existing ~~val would have to be written ~(~val)) ~~(place) val (the existing ~~val would have to be written ~(~val)) ~place val ~=place val ~place val(this looks like an arrow pointing to the place) ~(place) val Personally I think `~in(place) val` is perfectly fine. It's not the prettiest of syntaxes, but placement new should be very rare, and this allows us to avoid reserving `new` and continue to use ~ as the allocation operator. -Kevin -- Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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] Placement new and the loss of `new` to keywords
If looking like c++ is a goal, why not using the same naming convention as it for constructor? Having an init () function or new () function is generally a bad idea, it is just a name. I prefere personnally the new name. What i dont really like is the fn keyword, it is too short. func or function would have been perfectly acceptable. Le 30 nov. 2013 10:02, Kevin Ballard ke...@sb.org a écrit : `new` isn't self-documenting. It's merely consistent with C++, but consistency with C++ cannot be considered self-documentation because there are a great many programmers out there who have never touched C++ (or any language with a `new` operator). To someone who hasn't encountered `new` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. Is consistency with C++ really so important as to break what is now a pretty strong library convention? Especially since the replacement convention, as seen in PR #10697, is pretty bad (namely, using ::init() instead of ::new(); init() to me seems as though it should merely initialize a value, not construct a new value. Heck, the old Path convention of using Path(..) is better than Path::init(..)). As I've been arguing, `new` is not inherently self-documenting, and the confusion around ~ can be solved with proper documentation (just as a C++ programmer needs to be taught that `new` is the allocation operator, a Rust programmer would be taught that ~ is the allocation operator). As for placement new, while it needs to be supported in some fashion, it's going to be used pretty rarely, such that I don't think it's worth reserving a keyword just for that. We have existing keywords and syntactical tokens that can be used. Among my previous suggestions I'm fond of both `~in(place) val` and `~(place) val`. We've been moving stuff from the language into the libraries, yes. But losing ~ seems like losing a big part of the flavor of Rust, so to speak. And semantically speaking, both `new` and ~ are the same operator, so I don't think the closed-set nature of sigils is an issue in this case. -Kevin On Nov 30, 2013, at 12:34 AM, Patrick Walton pwal...@mozilla.com wrote: Plain new would allocate in the exchange heap by default. And yes, C++ syntax has always been a goal. That's why Rust has had curly braces from day one, for example. Of course it deviates when C++ syntax would lead to lack of expressivity (using let and colons before types allows for destructuring assignment, for example), but in general if the C++ way fits the language we go with it. IMHO sigils made sense back when there were a couple of ways to allocate that were built into the language and there was no facility for custom smart pointers. Now that we have moved all that stuff into the library, sigils seem to make less sense to me, as punctuation is a non-extensible closed set to borrow a term from linguistics. Besides, they were a very frequent source of confusion. Documentation is good, but being self-documenting is better. Patrick Kevin Ballard ke...@sb.org wrote: On Nov 29, 2013, at 11:26 PM, Patrick Walton pwal...@mozilla.com wrote: There's also the fact that the exchange heap is the default place to allocate, so anything that needs an object (e.g. in) doesn't work, as in Unique would probably be too verbose. `in Unique` is too verbose, but `new(Unique)` isn't? Looking like C++ is a goal of Rust, in any case... I thought C++ performance was a goal. Since when is C++ syntax considered to be a goal? -Kevin Patrick Kevin Ballard ke...@sb.org wrote: As I said in the IRC channel, the reason why users often don't realize that `~T` is allocation, is not a failure of syntax, but a failure of documentation. The only reason why a user would know that `new Foo` allocates is because they've been exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a
Re: [rust-dev] Ideas of small projects or improvements
Is is possible to get rid of this returnless return?
I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
Le 30 nov. 2013 19:59, György Andrasek jur...@gmail.com a écrit :
On 11/30/2013 07:41 PM, Pierre Talbot wrote:
Do you have suggestions that could fit well for this kind of project?
Make the following code compile:
```
fn foo() {
bar()
fn bar() {}
}
```
i.e. allow nested function declarations after a semicolonless return
expression.
___
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] Ideas of small projects or improvements
Sorry for this offtopic subject..
Le 30 nov. 2013 20:20, Benjamin Striegel ben.strie...@gmail.com a écrit
:
Is is possible to get rid of this returnless return?
I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
This isn't the point of this thread, and also I don't think anybody is
willing to revisit this issue. Consider that ship as having sailed beyond
the horizon.
On Sat, Nov 30, 2013 at 2:17 PM, Gaetan gae...@xeberon.net wrote:
Is is possible to get rid of this returnless return?
I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
Le 30 nov. 2013 19:59, György Andrasek jur...@gmail.com a écrit :
On 11/30/2013 07:41 PM, Pierre Talbot wrote:
Do you have suggestions that could fit well for this kind of project?
Make the following code compile:
```
fn foo() {
bar()
fn bar() {}
}
```
i.e. allow nested function declarations after a semicolonless return
expression.
___
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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Problem to use Encodable as fn parameter
I would prefere this function returns a str.
Le 29 nov. 2013 09:27, Philippe Delrieu philippe.delr...@free.fr a
écrit :
Thank you for the help. I've try this signature and I had an compile
error. I thought it came from the signature but the problem when from the
call.
It works now.
For the return type @mut MemWriter I work on the json doc and some example
of use. I can make the change. I didn't find the issue about it. Did you
create it?
Philippe
Le 28/11/2013 22:27, Erick Tryzelaar a écrit :
Good afternoon Phillippe,
Here's how to do it, assuming you're using rust 0.8 and the json library:
```
#[feature(managed_boxes)];
extern mod extra;
use std::io::mem::MemWriter;
use extra::serialize::{Encoder, Encodable};
use extra::json;
pub fn memory_encode
T: Encodablejson::Encoder
(to_encode_object: T) - @mut MemWriter {
//Serialize the object in a string using a writer
let m = @mut MemWriter::new();
let mut encoder = json::Encoder(m as @mut Writer);
to_encode_object.encode(mut encoder);
m
}
fn main() {
}
```
Regarding the trouble returning a `MemWriter` instead of a `@mut
MemWriter`, the easiest thing would be to fix library to use `mut ...`
instead of `@mut ...`. I'll put in a PR to do that.
On Thu, Nov 28, 2013 at 3:55 AM, Philippe Delrieu
philippe.delr...@free.fr wrote:
I try to develop a function that take a Encodable parameter but I have
the error wrong number of type arguments: expected 1 but found 0
pub fn memory_encode(to_encode_object: serialize::Encodable) - @mut
MemWriter {
//Serialize the object in a string using a writer
let m = @mut MemWriter::new();
let mut encoder = Encoder(m as @mut Writer);
to_encode_object.encode(mut encoder);
m
}
The encodable trait is :
pub trait EncodableS:Encoder {
fn encode(self, s: mut S);
}
I try this definition
memory_encodeT:serialize::EncodableEncoder(to_encode_object: T) -
@mut MemWriter
But I can't use the method with a struct that implement Encodable. The
error : mismatched types: expected `V31` but found ..
I have another question :
I would like to return a MemWriter and not a @mut MemWriter . I didn't
find a way to convert the @mut to ~
Philippe Delrieu
___
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] Mentoring + E-easy
agree ! - Gaetan 2013/11/26 Brandon Sanderson singingb...@gmail.com I'd definitely be in support of the change to easy tagging - I've seen quute a few issues where I've thought 'I could do this' but then realized I have no idea where to start. On 2013-11-26 12:59 AM, Corey Richardson co...@octayn.net wrote: Hey fellow Rusties, We have a fair number of new contributors, and my devious mind wonders how we can get more. My first thought was a new tag, E-mentored, where someone can volunteer to mentor someone through an E-easy issue. It's a very lightweight, non-formal process, and can hopefully give some more guidance to people who come into #rust asking for a good issue to get started with. This is intended for brand-new contributors, whereas I feel E-easy is a teeny bit misused. I also propose that, when tagging an issue as E-easy, a comment describing the nature of the fix and where (file + function ideal) one would look to start the fix. ___ 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] Mentoring + E-easy
I strongly support this kind of human to human interaction. When arriving in a new project, there is a lot things to know that is not properly described in a proper document, set of general rules, etc. Things like how to handle this error situation, or weird error message from the compiler. I don't want to annoy the mailing list with obvious error message, trivial situations. I think we can learn a lot from well organised documentation, but talking to someone who already know is extremely valuable. - Gaetan 2013/11/26 David Rajchenbach-Teller dtel...@mozilla.com It would be great if these bugs could be indexed by Bugsahoy: http://www.joshmatthews.net/bugsahoy/ This is the search system we use in Mozilla to lead contributors towards mentored tasks, so that would only make sense. Cheers, David On 11/26/13 9:58 AM, Corey Richardson wrote: Hey fellow Rusties, We have a fair number of new contributors, and my devious mind wonders how we can get more. My first thought was a new tag, E-mentored, where someone can volunteer to mentor someone through an E-easy issue. It's a very lightweight, non-formal process, and can hopefully give some more guidance to people who come into #rust asking for a good issue to get started with. This is intended for brand-new contributors, whereas I feel E-easy is a teeny bit misused. I also propose that, when tagging an issue as E-easy, a comment describing the nature of the fix and where (file + function ideal) one would look to start the fix. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ 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] A la python array access
Hello I'd like to know if you think it could be feasible to have a Python-like syntax for indices in array and vector? I find it so obvious and practical. let i = ~[1, 2, 3, 4, 5] i[1] returns a the second item (2) i[1:] returns ~[2, 3, 4, 5] i[:-2] return ~[1, 2, 3, 4] i[-2] returns ~[4, 5] i[1,-1] returns ~[2, 3, 4] Thanks ! - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] A la python array access
Hum that would prevent the step != 1 (allowed in python, but i never used it) Le 20 nov. 2013 11:59, Masklinn maskl...@masklinn.net a écrit : 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] list of all reserved keywords of the language
Let stick to the semantic:
- while (this condition is true) = execute until this condition becomes
false
- loop = make a loop until a manual break = while true.
However, i think the compiler should check that there is an exit condition
in 'loop' block. I hate reading code with while true without exit cond,
this is the kind of evilness that shouldnt exist in rust!
And why not preventing any 'break' condition in 'while' block? Having a
pure while construction can make the compiler happy (better optimisation?)
Le 20 nov. 2013 22:13, Gábor Lehel illiss...@gmail.com a écrit :
Hmm? I think you think I meant that `loop` should accept a condition in
front of the loop, like `while`? In fact my idea was sillier: just replace
all instances of `while foo { bar }` with
loop {
if !foo { break }
bar
}
On Wed, Nov 20, 2013 at 9:56 PM, Benjamin Striegel ben.strie...@gmail.com
wrote:
This is an even sillier idea, but then what about keeping `loop` and
dropping `while`?
I'm not sure this is possible to disambiguate in the grammar. You'd have
to be able to tell the difference between the infinite form:
loop block
...and the conditional form:
loop expr block
...while keeping in mind that expr can also be a block.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Your ship was destroyed in a monadic eruption.
___
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] autocomplete engine for rust
Hello I'm willing to help on this task, I think having a good completion library can help a lot smoothing the learning curve of a new language. I learned python in a few days with aptana, and I remember a few years ago how it was easy to write C++ with visual studio. Having an IDE integration is almost as important as having good tutorials. I'm also a newbe in Rust and I imagine you want to write in rust itself. I can help on the integration with sublime. - Gaetan 2013/11/19 Gokcehan Kara gokcehank...@gmail.com Hello folks, I have been thinking of working on an editor agnostic code helper library with an autocomplete engine for rust (since there isn't anything yet?) as a hobby project to get to know the internals of the compiler. Examples of similar projects in different languages include; - [youcompleteme](https://github.com/Valloric/YouCompleteMe) (C/C++/Objective-C/Objective-C++) (this one is specific to vim and a more general solution to autocompletion in vim but it includes a clang based completion engine for c family languages) - [merlin](https://github.com/def-lkb/merlin) (ocaml) (haven't actually used this but since we have many ocaml people I'm guessing some people might have) - [gocode](https://github.com/nsf/gocode) (go) - [jedi](https://github.com/davidhalter/jedi) (python) I have already started playing with the code but couldn't make much progress. What I had in mind was; 1) Implement a type under cursor functionality 2) Implement autocompletion functionality (i.e by looking up the methods and members of the type under cursor) 3) Wrap the whole thing with a server-client architecture (only if performance suffers too much otherwise) 4) Work on the bindings for my editor of choice as the showcase and ask the community for others Unfortunately I'm still at step 1. I have managed to parse a file until typecheck using `phase_3_run_analysis_passes` which gave me a `CrateAnalysis` including presumably the type context in `ty::ctxt`. From there I have only checked two things so far, (1) `items: ast_map::map` which is basically a map from `NodeId` to the enum `ast_node` and (2) `node_types: node_type_table` which is similarly a map from `uint` to `t`. `t` seems to represent types which is what I was looking for although I couldn't find anything related to type names so far. I have found a few id's instead that I have yet to comprehend which then made me think that it might be the case that types themselves might be stored only with an id instead of a name. If this is the case, it may still be possible to work on autocomplete functionality by skipping type under cursor functionality. Any insight? Some more general questions are; - How feasible is this project with the current state of the compiler? - How difficult would it be for a newbie (to both rustc and compilers)? - Shall I open an issue for this? Thanks, Gokcehan ___ 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] list of all reserved keywords of the language
hello Where can I find an exhaustive list of the keywords defined by the language? I want to add basic syntax highlighting support to the rust language to some web editors and I don't know all of them yet. Thanks. - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust docs
That was my point on another thread. I think it's best to have a top-bottom approach, ie, decribe everything else BUT the language first (how crates works, how to compile, how to test,...) and then introduce the memory concepts, etc. I think the technical writer is a full time job, how to present things properly is not easy to do. He may have better way of introducing the language. I tend to agree with the assertion that its not a level of quality we can achieve with collaborating works, sadly. - Gaetan 2013/11/19 Thad Guidry thadgui...@gmail.com I tend to agree with this, think that a collaborative approach is unlikely to produce a consistent and high quality tutorial. I don't want to discourage anybody but my current opinion is that we should hire an experienced technical writer to do this piece especially, with input from the wider community. Where I think collaboration is more likely to produce something nice is in a 'cookbook' style document, of which several people have already worked on seperately. Also of course API docs and the reference manual are places where individuals can plug in their own sections without impacting the overall narrative flow. So I spent this evening going through the tutorial (.08). As an outsider to Rust, I can tell you it does not fit any model of a tutorial, but instead is an elongated language reference broken down into feature sections. Which is highly useful in its design, and does say This tutorial assumes that the reader is already familiar with one or more languages in the C family. Understanding of pointers and general memory management techniques will help. BUT... It was not until section 17, that I finally met with a simple program that could compile. That was 2 1/2 hours later before I was able to DO SOMETHING. I would encourage the Mozilla team to hire a technical writer as Brian suggests, that would turn the tutorial upside down... Start with something fun and entertaining in under 10 or 20 lines of Rust, that would amuse and provide hackability to tweak and play with values, mutability, and seeing the stack pop itself (half the developers in the world, do not know or have to worry about a stack..but of course should in any decent systems language :-) ), and then introduce garbage collecting, etc. Introduce compile-able examples from the start, and continue with working examples that actually produce errors and let the user come to grips with the syntax compiler error output, while coaching them through fixing the errors, and learning the do's and don'ts of Rust's current best practices. That would be a mighty fine tutorial and the makings of a book for Rust itself. 2 cents and a haircut and I wish the team tremendous success on finding a talented writer, -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ 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] Please simplify the syntax for Great Justice
I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com Is there any specific issue with the current tutorial section on boxes? It mentions every case where owned boxes are useful. http://static.rust-lang.org/doc/master/tutorial.html#boxes I keep hearing that it should be better, but have yet to see any hints on where it falls short. It's not going to change if no one can point out where it confuses them. I do want to rewrite it in a less boring style by having it be an introduction to these concepts by implementing a linked list, but I won't be changing the *content* (at least of Boxes). ___ 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] list of all reserved keywords of the language
can you give a little review? https://github.com/Stibbons/crayon-syntax-rust - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:12 AM, Josh Matthews j...@joshmatthews.net wrote: http://static.rust-lang.org/doc/master/rust.html#keywords Cheers, Josh That's missing `proc`, at the very least :). Perhaps it would be best to look at `libsyntax/parse/token.rs`. Just ignore __LogLevel (it existing is a bug) and you likely don't want to bother highlighting non-functional reserved ones. ___ 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
In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:25 AM, Gaetan gae...@xeberon.net wrote: I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. I'm specifically talking about the `Boxes` section in the tutorial and not the whole picture. I keep hearing that the coverage of `~` it's confusing - so can someone elaborate? Rewriting the coverage of boxes and references by walking through the implementation of some data structures is something I'm willing to do, but in my opinion that section is now quite good, other than being dry and not presenting interesting code samples for the use cases it describes. ___ 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
Can I advise to have a certain constitency in the semantics? Not having ~foo, *foo, Rc, Gc. I would rather prefere having ~foo *foo foo @foo of Somethingfoo, otherfoo, Rc foo By the way, I like pretty much your pronoums thing, this help understanding :) - Gaetan 2013/11/19 Gábor Lehel illiss...@gmail.com In case this helps, I recently noticed that the sigils correspond to possessive pronouns: '~' = my, '' = their, '@' = our Of course, `@` might be going away, but `Rc`, `Gc`, and so forth all (will) have the same intuitive content, only different representations (among other properties). Similarly `~Foo` and plain `Foo` both mean my, while having differences in other areas, in which case yeah, telling you that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't help you if you don't know what heap allocation is about. But maybe this is something. On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano j.boggi...@seld.bewrote: 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 -- Your ship was destroyed in a monadic eruption. ___ 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] Please simplify the syntax for Great Justice
+1 semantics is so important Le 19 nov. 2013 12:22, spir denis.s...@gmail.com a écrit : On 11/19/2013 10:12 AM, Jordi Boggiano wrote: 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. +++ This is what I'm asking for about pointer variety and memory management in Rust. What does this all mean? Semantics, please ;-) (I mean human semantics, no machine operations) 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] Please simplify the syntax for Great Justice
The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan 2013/11/19 Gaetan gae...@xeberon.net In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:25 AM, Gaetan gae...@xeberon.net wrote: I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. I'm specifically talking about the `Boxes` section in the tutorial and not the whole picture. I keep hearing that the coverage of `~` it's confusing - so can someone elaborate? Rewriting the coverage of boxes and references by walking through the implementation of some data structures is something I'm willing to do, but in my opinion that section is now quite good, other than being dry and not presenting interesting code samples for the use cases it describes. ___ 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
I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] list of all reserved keywords of the language
Sorry, I rephrase: Let do spawn high level functions like each or spawn and not confuse it with loop or while. - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 6:42 AM, Gaetan gae...@xeberon.net wrote: I d prefere letting do launch tasks and don t add confusion. Tasks are part of the standard library, and don't have any presence at a language level. ___ 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
I think it is one of the first thing to explain, actually... Playing with strings, using the method in std or extra requires to understand it. I wanted to use (and improve) extra::url and others (like std::path,...) and... I was simply lost with all of these ~str... and nothing in the manual or tutorial. - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:40 AM, Gaetan gae...@xeberon.net wrote: I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan I don't want to have `~str` and `~[T]` in the language, so I'm not really motivated to spend time trying to paper over the confusion caused by them. I doubt most users of Rust realize that ~([1, 2, 3]) and ~[1, 2, 3] have different types, and dynamically sized types are not going to fix this. ___ 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
Sorry, but it's not clear. the only occurences of ~str are in Declaring and implementing traits section... Maybe by adding more string specific examples would help... And a special section one why ~str is not a ~T would be so useful! - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:52 AM, Gaetan gae...@xeberon.net wrote: I think it is one of the first thing to explain, actually... Playing with strings, using the method in std or extra requires to understand it. I wanted to use (and improve) extra::url and others (like std::path,...) and... I was simply lost with all of these ~str... and nothing in the manual or tutorial. - Gaetan It is covered, I rewrote the section on it recently: http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings It doesn't go out of the way to explain that they're not owned boxes, but I don't think it should. It's a confusing language wart and should be fixed as far as I am concerned. ___ 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
However, I want to highlight it is really appreciable that you, the rust team, are so open to our question. Just wanted to give you this feedback, I don't want to be held like the guy who criticize the current work, I know very much that is could be very annoying. Just willing to help :) - Gaetan 2013/11/19 Gaetan gae...@xeberon.net I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust docs
I think it's better to enhance the extra::json lib itself and write proper module documentation, with samples, use case etc. My reference is the QT documentation. You never open and samples or even the QT source code, everything is in the module documentation. - Gaetan 2013/11/19 Philippe Delrieu philippe.delr...@free.fr Hello, I would like to share my experience about the Rust doc and the tutorial. I've just started to learn Rust and I've decided to use it on a project I work on. Like everybody I read the Rust tutorial. It's not a really a tutorial for beginner but it do a good job in presenting Rust and its mains concept. I found other tutorial on the web and in my opinion what is missing the more is sample code. The Rust lib is huge and there is no code. In my project I have to use Json serialization. So I wanted to use the json lib in extra lib and I really spend some time to make a simple code works. I was very near to write my own lib. json.rs is a little complicated for a newbie. There are some test case at the end but it tests the lib and not what I want to do with it. For example there is no serialization of an object. I search the web and I found some old example (not compatible with the master lib) and no object serialization. So what I think is that it would be great is to construct a repository of sample code of the Rust lib that show how to use the lib. I'm ok to write and maintain some sample like one on json. I think it would be great to host all these sample in the same repository and to have the same organization for all sample. The second reason tu use a share repository is that the sample has to be made in the spirit of Rust to help understand it. For that the sample must be checked and modified by more experienced rust developer. It's easier when the code is in a common repository. Pḧilippe ___ 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] Rust docs
Also, what we set up in our scrum team is targetted doc stories inside each sprint. Let's say that over the next month, the objective is to improve a set of module doc, ie, a list of very useful std or extra lib that is not properly documented. For instance, the next month we target on improving json or extra::path, and enhance them until they become golden star level. And the next month or sprint, we focus on other modules It's easier to focus people like this that just telling you can take whichever module you want and improve them. It just work better, we discovered. - Gaetan 2013/11/19 Gaetan gae...@xeberon.net I think it's better to enhance the extra::json lib itself and write proper module documentation, with samples, use case etc. My reference is the QT documentation. You never open and samples or even the QT source code, everything is in the module documentation. - Gaetan 2013/11/19 Philippe Delrieu philippe.delr...@free.fr Hello, I would like to share my experience about the Rust doc and the tutorial. I've just started to learn Rust and I've decided to use it on a project I work on. Like everybody I read the Rust tutorial. It's not a really a tutorial for beginner but it do a good job in presenting Rust and its mains concept. I found other tutorial on the web and in my opinion what is missing the more is sample code. The Rust lib is huge and there is no code. In my project I have to use Json serialization. So I wanted to use the json lib in extra lib and I really spend some time to make a simple code works. I was very near to write my own lib. json.rs is a little complicated for a newbie. There are some test case at the end but it tests the lib and not what I want to do with it. For example there is no serialization of an object. I search the web and I found some old example (not compatible with the master lib) and no object serialization. So what I think is that it would be great is to construct a repository of sample code of the Rust lib that show how to use the lib. I'm ok to write and maintain some sample like one on json. I think it would be great to host all these sample in the same repository and to have the same organization for all sample. The second reason tu use a share repository is that the sample has to be made in the spirit of Rust to help understand it. For that the sample must be checked and modified by more experienced rust developer. It's easier when the code is in a common repository. Pḧilippe ___ 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] Rust docs
I am willing to help also but i find it quite hard to setup the environnement properly. Is these a tutorial for this point? Le 19 nov. 2013 14:58, Philippe Delrieu philippe.delr...@free.fr a écrit : I'am ok to add sample code in json.rs. how can I do? I think I will have other sample code for other lib in a few days. I'll wait that the lib is open to doc enhancement or I put it as it come and how can it be managed. Philippe Le 19/11/2013 14:48, Gaetan a écrit : Also, what we set up in our scrum team is targetted doc stories inside each sprint. Let's say that over the next month, the objective is to improve a set of module doc, ie, a list of very useful std or extra lib that is not properly documented. For instance, the next month we target on improving json or extra::path, and enhance them until they become golden star level. And the next month or sprint, we focus on other modules It's easier to focus people like this that just telling you can take whichever module you want and improve them. It just work better, we discovered. - Gaetan 2013/11/19 Gaetan gae...@xeberon.net I think it's better to enhance the extra::json lib itself and write proper module documentation, with samples, use case etc. My reference is the QT documentation. You never open and samples or even the QT source code, everything is in the module documentation. - Gaetan 2013/11/19 Philippe Delrieu philippe.delr...@free.fr Hello, I would like to share my experience about the Rust doc and the tutorial. I've just started to learn Rust and I've decided to use it on a project I work on. Like everybody I read the Rust tutorial. It's not a really a tutorial for beginner but it do a good job in presenting Rust and its mains concept. I found other tutorial on the web and in my opinion what is missing the more is sample code. The Rust lib is huge and there is no code. In my project I have to use Json serialization. So I wanted to use the json lib in extra lib and I really spend some time to make a simple code works. I was very near to write my own lib. json.rs is a little complicated for a newbie. There are some test case at the end but it tests the lib and not what I want to do with it. For example there is no serialization of an object. I search the web and I found some old example (not compatible with the master lib) and no object serialization. So what I think is that it would be great is to construct a repository of sample code of the Rust lib that show how to use the lib. I'm ok to write and maintain some sample like one on json. I think it would be great to host all these sample in the same repository and to have the same organization for all sample. The second reason tu use a share repository is that the sample has to be made in the spirit of Rust to help understand it. For that the sample must be checked and modified by more experienced rust developer. It's easier when the code is in a common repository. Pḧilippe ___ 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] autocomplete engine for rust
I think we can write in rust and perhaps reuse part of the compiler, but we cannot allow to support only fully compiler crates. It may be possible to begin a draft in language such as python (YouCompleteMe seems to be written mostly in python) - Gaetan 2013/11/19 Gokcehan Kara gokcehank...@gmail.com I'm willing to help on this task, I think having a good completion library can help a lot smoothing the learning curve of a new language. I learned python in a few days with aptana, and I remember a few years ago how it was easy to write C++ with visual studio. Having an IDE integration is almost as important as having good tutorials. That's great. I agree that it would be nice for newbies and I think also for others as most people are already quite spoiled by the capabilities of modern IDE's these days. I'm also a newbe in Rust and I imagine you want to write in rust itself. I can help on the integration with sublime. I was hoping to write in rust because I don't want to implement/maintain a parser and typechecker from scratch. I was very pleased to see that it's possible to access everything in `librustc` and `libsyntax` with a simple `extern`, not sure if this will be removed later. rustfind (https://github.com/dobkeratops/rustfind) does this and more, for crates that compile. I wasn't aware of that, looks very nice indeed. I will take a look and see if I can contribute somehow when I have some time. Not very, for the general case. If you want autocompletion as you type, you currently need to have a fully-compilable crate. Otherwise, parsing or typechecking or something else will fail and you won't be able to get any results. rustc is currently very all-or-nothing. It's a bummer. Are there any plans to implement some error recovery to rustc? But, you can get useful information for completion out of an already-compiling crate, though I'm not sure how much better it would be than what etags already does. It has been some time since I last tried tags for autocompletion but it wasn't very accurate as far as I remember. As far as I know you also need some editor plugin for this, something like [OmniCppComplete]( http://www.vim.org/scripts/script.php?script_id=1520) which is basically a cpp parser implemented in vimscript. Very, since it would require reworking most of the compiler ;) :) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] tutorial (bis)
I ve started the github project now i just need to learn rust... https://github.com/Stibbons/rust-for-pythonists Le 18 nov. 2013 21:10, Brian Anderson bander...@mozilla.com a écrit : On 11/15/2013 06:24 AM, Gaetan wrote: I would love a documentation Rust for Pythonist or Rust for C++'iste. I don't like the Wiki page. I think the official documentation homepage should be a nice, beautiful http://doc.rust-lang.org/http://static.rust-lang.org/. Period. It should link all official documentation in a logical way. Maybe it should provide a link to the wiki page with only incubating documentation. I think it should be derived from rst/markdown files in conf, closely linked to the current version of rust lang. Maybe divided in several modules (the summary for rust 0.8 derives from files in the rust 0.8 branch, for master files are on master, branch...). I would take a patch that does this. - Gaetan 2013/11/15 Daniel Micay danielmi...@gmail.com On Fri, Nov 15, 2013 at 7:46 AM, spir denis.s...@gmail.com wrote: I'm exploring the tutorial Rust for Rubyists at [http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for rubyists, as stated in the introduction. Looks pretty good to me (just my opinion), should definitely be pointed to from the Rust Docs page at [https://github.com/mozilla/rust/wiki/Docs], and in good place. As a tutorial, it is in my view far better than the official one, and is up-to-date (Rust 0.8), so maybe even just replace it; with a warning note. The official tutorial is not a bad doc in itself (I guess) but is definitely not a _tutorial_: in fact, it requires quite a knowledge of Rust, its fundamental concepts and jargon. Rust for Rubyists certainly has room for improvement, but it _is_ for sure a tutorial. I would definitely suggest to start writing a new official tutorial by using Rust for Rubyists as raw material. A first pass may be to make it slightly more general, just requiring prior programming experience; Rust definitely is not a language for programming novices, anyway. Denis The tutorial is currently quite flawed and has ended up being a list of language features with overviews and low quality examples. Parts of it are approaching the right level of information, but it's not written in the style expected of a tutorial. I think it's very important to cover the core language features like boxes and references at a high level. The unique and least approachable features need great introductory coverage. I recently replaced the old sections on owned boxes, vectors and strings, so any concrete feedback on those would be helpful. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing listRust-dev@mozilla.orghttps://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] tutorial (bis)
I would love a documentation Rust for Pythonist or Rust for C++'iste. I don't like the Wiki page. I think the official documentation homepage should be a nice, beautiful http://doc.rust-lang.org/http://static.rust-lang.org/. Period. It should link all official documentation in a logical way. Maybe it should provide a link to the wiki page with only incubating documentation. I think it should be derived from rst/markdown files in conf, closely linked to the current version of rust lang. Maybe divided in several modules (the summary for rust 0.8 derives from files in the rust 0.8 branch, for master files are on master, branch...). - Gaetan 2013/11/15 Daniel Micay danielmi...@gmail.com On Fri, Nov 15, 2013 at 7:46 AM, spir denis.s...@gmail.com wrote: I'm exploring the tutorial Rust for Rubyists at [http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for rubyists, as stated in the introduction. Looks pretty good to me (just my opinion), should definitely be pointed to from the Rust Docs page at [https://github.com/mozilla/rust/wiki/Docs], and in good place. As a tutorial, it is in my view far better than the official one, and is up-to-date (Rust 0.8), so maybe even just replace it; with a warning note. The official tutorial is not a bad doc in itself (I guess) but is definitely not a _tutorial_: in fact, it requires quite a knowledge of Rust, its fundamental concepts and jargon. Rust for Rubyists certainly has room for improvement, but it _is_ for sure a tutorial. I would definitely suggest to start writing a new official tutorial by using Rust for Rubyists as raw material. A first pass may be to make it slightly more general, just requiring prior programming experience; Rust definitely is not a language for programming novices, anyway. Denis The tutorial is currently quite flawed and has ended up being a list of language features with overviews and low quality examples. Parts of it are approaching the right level of information, but it's not written in the style expected of a tutorial. I think it's very important to cover the core language features like boxes and references at a high level. The unique and least approachable features need great introductory coverage. I recently replaced the old sections on owned boxes, vectors and strings, so any concrete feedback on those would be helpful. ___ 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] tutorial (bis)
after reading this doc, I would love to have: - have a link at the bottom page to the github project - submit one or several pullrequest - doc is magically updated. I'm investigating on this matter to ease documentation. That's is quite interesting, because in my everyday job (I'm a python developer for a buildbot derived project) I'm in a write tools to ease code documentation and user manual maintainance mood :) Gaetan - Gaetan 2013/11/15 Daniel Micay danielmi...@gmail.com On Fri, Nov 15, 2013 at 7:46 AM, spir denis.s...@gmail.com wrote: I'm exploring the tutorial Rust for Rubyists at [http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for rubyists, as stated in the introduction. Looks pretty good to me (just my opinion), should definitely be pointed to from the Rust Docs page at [https://github.com/mozilla/rust/wiki/Docs], and in good place. As a tutorial, it is in my view far better than the official one, and is up-to-date (Rust 0.8), so maybe even just replace it; with a warning note. The official tutorial is not a bad doc in itself (I guess) but is definitely not a _tutorial_: in fact, it requires quite a knowledge of Rust, its fundamental concepts and jargon. Rust for Rubyists certainly has room for improvement, but it _is_ for sure a tutorial. I would definitely suggest to start writing a new official tutorial by using Rust for Rubyists as raw material. A first pass may be to make it slightly more general, just requiring prior programming experience; Rust definitely is not a language for programming novices, anyway. Denis The tutorial is currently quite flawed and has ended up being a list of language features with overviews and low quality examples. Parts of it are approaching the right level of information, but it's not written in the style expected of a tutorial. I think it's very important to cover the core language features like boxes and references at a high level. The unique and least approachable features need great introductory coverage. I recently replaced the old sections on owned boxes, vectors and strings, so any concrete feedback on those would be helpful. ___ 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] tutorial (bis)
I agree on the semantic point. The job of technical writer is quite a talent to have, not anyone can easily vulgarize concept and present them in a logical way. This is pedagogy and quite hard to set up in a developer's brain. However, on tutorial I think there is a flaw: most of the a time, just the source code itsn't enough. If you want to test and play with it, you need some other files (makefiles, crates declarations, ...) to have it running. While it's good to have the code sample right on the screen, if I want to take it and paste it to test its behavior, i have to deploy a large among of work, to find similar compile samples and replace the files. I would recommend to have some kind of package with makefile and source code easily accessible, described early in the tutorial. Not completly described, but it basically say: don't try (yet) to understand what all these Makefile and lib.rs and other stuff do, just edit the sample.rs file and type make. I would love to have this package automatized and freely available on each source code trace in the tutorial. - Gaetan 2013/11/15 Daniel Glazman d.glaz...@partner.samsung.com On 15/11/13 15:59, Daniel Micay wrote: It's gets across most of the information, but it doesn't have a very compelling flow of examples. It teaches how to use language features rather than walking through building something with those features. For example, the sections on owned boxes and borrowed pointers could be done by walking through the implementation of a singly-linked list. It's incredibly hard to actually do this without using too many features before they've been introduced. Exactly my point. Marijn (hey Marijn!!!), nobody hates your tutorial. It's an excellent document, but made for programming language specialists with an already quite advanced level. My comment was an optimization comment only: tweaking a bit the way examples are chosen and designed, and explaining better some complex vocabularies, it will attract more people to Rust and will help smoothing the learning curve. That's all. /Daniel ___ 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] Rust docs
I would love helping on this matter, I'm use to setting up automatic documentation generation (rst, sphinx, doxygen,...). - Gaetan 2013/11/14 Philip Herron redbr...@gcc.gnu.org I would defineltly like to see a clone of the python tutorial because it really does it so well going inch by inch building up what way things work i am not a web developer but would love to write content i wonder is it possible to start a github project for this using sphinx i think it uses isn't it? On 14 November 2013 15:38, Corey Richardson co...@octayn.net wrote: On Thu, Nov 14, 2013 at 10:03 AM, Daniel Glazman d.glaz...@partner.samsung.com wrote: The Tutorial is the entry point for all people willing to investigate Rust and/or contribute to Servo. I think that document is super precious, super-important. Unfortunately, I don't think it is really a tutorial but only a lighter manual. Examples are here even more important than in the case of the Manual above. A good Tutorial is often built around one single programming task that becomes more and more complex as more features of the language are read and known. Furthermore, the Tutorial has clearly adopted the language complexity of the reference manual, something that I think should be in general avoided. I also think all examples should be buildable and produce a readable result on the console even if that result is a build or execution error. That would drastically help the reader. All in all, I think the Tutorial needs some love and probably a technical writer who is not working on the guts of Rust, someone who could vulgarize the notions of the Manual into an easy-to-read, simple-to-experiment, step-by-step tutorial and avoiding in general vocabulary inherited from programming language science. I agree, partially. I think Rust for Rubyists fills this role quite well for now. Generally I think the language tutorial should not try to hide complexity or paper over things, at the very least so it can be complete and correct. I think the Python tutorial is a good benchmark. We might even be able to rip off the Python tutorial's structure wholesale. The on-boarding process is still very rough. Maybe some sort of live-comment system would work well for finding pain points, where one can add comments/feedback while reading the tutorial. ___ 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] Rust docs
do you have a buildbot or jenkins for the rust ? I don't think travis could push html pages to a remote repository, do it? - Gaetan 2013/11/14 Benjamin Striegel ben.strie...@gmail.com I would welcome such an effort, and suggest that it live as its own project, outside of the Rust repo. We really aren't set up currently to handle rapid and frequent documentation changes. Once it gets to a reasonable level of maturity we could then give it a mention from the main tutorial, and then once it's ready we could replace the current tutorial entirely. On Thu, Nov 14, 2013 at 11:58 AM, Gaetan gae...@xeberon.net wrote: I would love helping on this matter, I'm use to setting up automatic documentation generation (rst, sphinx, doxygen,...). - Gaetan 2013/11/14 Philip Herron redbr...@gcc.gnu.org I would defineltly like to see a clone of the python tutorial because it really does it so well going inch by inch building up what way things work i am not a web developer but would love to write content i wonder is it possible to start a github project for this using sphinx i think it uses isn't it? On 14 November 2013 15:38, Corey Richardson co...@octayn.net wrote: On Thu, Nov 14, 2013 at 10:03 AM, Daniel Glazman d.glaz...@partner.samsung.com wrote: The Tutorial is the entry point for all people willing to investigate Rust and/or contribute to Servo. I think that document is super precious, super-important. Unfortunately, I don't think it is really a tutorial but only a lighter manual. Examples are here even more important than in the case of the Manual above. A good Tutorial is often built around one single programming task that becomes more and more complex as more features of the language are read and known. Furthermore, the Tutorial has clearly adopted the language complexity of the reference manual, something that I think should be in general avoided. I also think all examples should be buildable and produce a readable result on the console even if that result is a build or execution error. That would drastically help the reader. All in all, I think the Tutorial needs some love and probably a technical writer who is not working on the guts of Rust, someone who could vulgarize the notions of the Manual into an easy-to-read, simple-to-experiment, step-by-step tutorial and avoiding in general vocabulary inherited from programming language science. I agree, partially. I think Rust for Rubyists fills this role quite well for now. Generally I think the language tutorial should not try to hide complexity or paper over things, at the very least so it can be complete and correct. I think the Python tutorial is a good benchmark. We might even be able to rip off the Python tutorial's structure wholesale. The on-boarding process is still very rough. Maybe some sort of live-comment system would work well for finding pain points, where one can add comments/feedback while reading the tutorial. ___ 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 ___ 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] library name libstd and libextra
I have a question about the two files libextra and libstd that are installed by rust compiler. Can they be called by any normal average program? If so, shouldn't we document how? If this has no sense, I suggest to rename them to something like libruststd or librustextra to avoid naming conflict with system libraries. We can also move to a subdirectory of /usr/lib, like /usr/lib/rust. What do you think about this? - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust docs
good :) so, what is missing to have an automatic generation of html page from a github page? - Gaetan 2013/11/14 Corey Richardson co...@octayn.net Travis could, but then anyone could (since the travis.yml is public and it'd need credentials to the repo). We have a buildbot, buildbot.rust-lang.org On Thu, Nov 14, 2013 at 12:39 PM, Gaetan gae...@xeberon.net wrote: do you have a buildbot or jenkins for the rust ? I don't think travis could push html pages to a remote repository, do it? - Gaetan 2013/11/14 Benjamin Striegel ben.strie...@gmail.com I would welcome such an effort, and suggest that it live as its own project, outside of the Rust repo. We really aren't set up currently to handle rapid and frequent documentation changes. Once it gets to a reasonable level of maturity we could then give it a mention from the main tutorial, and then once it's ready we could replace the current tutorial entirely. On Thu, Nov 14, 2013 at 11:58 AM, Gaetan gae...@xeberon.net wrote: I would love helping on this matter, I'm use to setting up automatic documentation generation (rst, sphinx, doxygen,...). - Gaetan 2013/11/14 Philip Herron redbr...@gcc.gnu.org I would defineltly like to see a clone of the python tutorial because it really does it so well going inch by inch building up what way things work i am not a web developer but would love to write content i wonder is it possible to start a github project for this using sphinx i think it uses isn't it? On 14 November 2013 15:38, Corey Richardson co...@octayn.net wrote: On Thu, Nov 14, 2013 at 10:03 AM, Daniel Glazman d.glaz...@partner.samsung.com wrote: The Tutorial is the entry point for all people willing to investigate Rust and/or contribute to Servo. I think that document is super precious, super-important. Unfortunately, I don't think it is really a tutorial but only a lighter manual. Examples are here even more important than in the case of the Manual above. A good Tutorial is often built around one single programming task that becomes more and more complex as more features of the language are read and known. Furthermore, the Tutorial has clearly adopted the language complexity of the reference manual, something that I think should be in general avoided. I also think all examples should be buildable and produce a readable result on the console even if that result is a build or execution error. That would drastically help the reader. All in all, I think the Tutorial needs some love and probably a technical writer who is not working on the guts of Rust, someone who could vulgarize the notions of the Manual into an easy-to-read, simple-to-experiment, step-by-step tutorial and avoiding in general vocabulary inherited from programming language science. I agree, partially. I think Rust for Rubyists fills this role quite well for now. Generally I think the language tutorial should not try to hide complexity or paper over things, at the very least so it can be complete and correct. I think the Python tutorial is a good benchmark. We might even be able to rip off the Python tutorial's structure wholesale. The on-boarding process is still very rough. Maybe some sort of live-comment system would work well for finding pain points, where one can add comments/feedback while reading the tutorial. ___ 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 ___ 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] Please simplify the syntax for Great Justice
The name itself is standard, like it is the default settings... Le 12 nov. 2013 02:35, Steven Fackler sfack...@gmail.com a écrit : base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. That is not true. If you are going to be putting the Base64 encoded data into a URL you're going to have to use URL_SAFE instead of STANDARD. If you're trying to send an email, you'll need to use MIME instead of STANDARD. If you're talking to a service that requires one of the ~10 other variants of Base64, you'll need to use a custom config struct. Steven Fackler On Mon, Nov 11, 2013 at 5:23 PM, Brendan Zabarauskas bjz...@yahoo.com.auwrote: On 12 Nov 2013, at 10:12 am, John Clements cleme...@brinckerhoff.org wrote: If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! It would be nice if we could: - A: desugar Rust into a small kernel language - B: allow rustc to take in some sort of raw AST data (not sure if that’s already possible) - C: have a way of outputting the AST data in a certain syntax. That would allow folks like me to have a nice Haskelly syntax as well as an s-expr style! Heh. ~Brendan ___ 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] Please simplify the syntax for Great Justice
More concretely, a good ide with completion, the right snippets and contextual help is very helpful for learning new language. I thing this could be a good idea to have an official set of snippets, typical every day codes, that can be used to create a common contextual helps for editors (vim, sublim,...) When i arrive in a new language, i m used to gather the common experience and write some automatisation tool and documentation to have a unique point of entry for all what should i do in this situation. This covers: - code styling - source organisation - file handling (open/close) - error handling - for python, import lines organisation - argument passing... Le 12 nov. 2013 11:35, Diggory Hardy li...@dhardy.name a écrit : My opinion is that clear semantics and good documentation is much more important than familiar syntax. Besides, it's not too closely C++ syntax; for example `let x : T = v` is much closer to Scala's `val x : T = v` than C++'s `T x = v`. (This is a good choice, as anyone who know's why C++ has a `typename` keyword will realise.) But why is this discussion continuing here? The developers have already stated that major type changes are not an option for Rust 1.0. I have been considering some (fairly major) syntax variations myself, but here is not the place; if you want to try out some other syntax then why not write a compiler extension which allows the option of different syntax through a different file extension (e.g. .rs2) or some such switch? I for one am not convinced that pure syntax changes can make that big a difference; far more interesting would be an interactive IDE which lets the programmer write plain English (or restricted English or German or Japanese or whatever you like) and attempts to infer what code is meant. Of course English is not precise enough to specify exact code (without a _lot_ of words), so the interesting part would be how to make the IDE smart enough and interact with the programmer well enough to produce good code easily. (The point of this in the first place is to allow the programmer to write things like sort this list or give me an n*n identity matrix without expecting the programmer to know in advance how the relevant APIs work.) On Tuesday 12 November 2013 10:59:16 Gábor Lehel wrote: Does anyone have empirical data (or even anecdotes) about whether or not C++ hackers find Rust's syntax appealing? :-) On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote: On 11/11/2013 09:46 PM, Corey Richardson wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). I don't think Rust can succeed as a language if it massively resembles the language it intends to offset (C++). 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Just an humble opinion. I kind of like saying that the code i write must be beautiful. The langage should allow to write beautiful code. It is more than a personnal point of view, it is also very important. if it is a pain in the ... to use an essential feature, or if i will never remember how to do it without copy paste because there is no logic behind it, i will have a bad opinion on the langage itself. The real question are: - as a typicial rust programmer, will i see the usage of str or ~str as logic or will i have to copy paste some sample code each time because it works this way in rust - the boilder plates theory. Can i avoid them? I think a good modern language should allow me to avoid writing useless code, each time the same things. That is the real mess with C++. Gaetan Le samedi 9 novembre 2013, spir a écrit : On 11/09/2013 06:43 AM, Kevin Ballard wrote: On Nov 8, 2013, at 9:38 PM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $Hello, world!; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- - Gaetan ___ 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
Can we have Two rust? The first one would be easy to learn, easy to read, and do most of ones would expect: on demand garbage collector, traits, Owned pointers,... The second one would include all advanced feature we actually don t need everyday. Of course, we don t want to split the language, but rather présent the current things differently. The tutorials are a good starting point however, the rest of the documentations are quite complex. I would be very delighted to help on this matter. There could be some effort on simplification of the API (std/extra): provides just the right functions first, and allow all flexibility in a second step, maybe in an advanced functions parts in each API doc. For instance url.rs. To parse a string, you have to write this: let u = url::from_str(urlstring).unwrap(); I would propose this solution: let u = parse_url(urlstring); = simpler, easier to read, easier to remember ! Of course, the unwrap thing would still be here. base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. There are some minor change to the API that would help a lot the learning of this language, along with adding more code sample in the documentation. After year of writing C++ code with complex API (boost) I enjoy writing with python which seems to provide just the right methods I need. I'll willing to help, but I don't easily find a easy starting point :) Gaetan Le lundi 11 novembre 2013, Brian Anderson a écrit : On 11/11/2013 01:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: * By this point, I'm aware that this is unlikely to happen.* I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. I am hoping that the developers of Rust will consider this issue important enough to put more thought into it. I am aware that I am jumping into an issue at a point in time that's considered late in the game. From the outside, I can say (with confidence), that Rust is still a nearly unheard-of language, and therefore it still has wiggle-room for improvement, even if the Rust developers and community, because they have been immersed in the language for quite some time, cannot see that this is in fact true. I also believe Tim when he said that years of effort went into designing the syntax. However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Looking at the Influenced By section on Wikipedia seems to indicate that the answer to these questions is, again, no. The answer is 'yes'. The designers of Rust are well aware of these languages and many others and have debated syntax issues repeatedly (as it is the most beloved pasttime of language designers). The current syntax was designed very intentionally the way it is. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: OptionUserInfo,
host: ~str,
port: Option~str,
path: ~str,
query: Query,
fragment: Option~str
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: str, c: char) - (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~);
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: OptionUserInfo,
host: str,
port: Optionstr,
path: str,
query: Query,
fragment: Optionstr
}
pub type Query = [(str, str)];
fn split_char_first(s: str, c: char) - (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), );
}
}
KISS !
-
Gaetan
2013/11/8 Jason Fager jfa...@gmail.com
Can you speak a little to the practical differences between owned boxes
and ~[T]/~str? How does the difference affect how I should use each?
On Thursday, November 7, 2013, Daniel Micay wrote:
On Thu, Nov 7, 2013 at 6:32 PM, Liigo Zhuang com.li...@gmail.com wrote:
Owned boxes shouldn't be commonly used. There's close to no reason to
use one for anything but a recursive data structure or in rare cases for an
owned trait object.
http://static.rust-lang.org/doc/master/tutorial.html#boxes
It's important to note that ~[T] and ~str are not owned boxes. They're
just sugar for dynamic arrays, and are common containers.
It's so confusing. If it's not owned box, why not remove ~? Make str
default be dynamic should OK.
It wouldn't be okay for every string literal to result in a heap
allocation.
___
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] About owned pointer
// An exchange heap (owned) stringlet exchange_crayons: ~str = ~Black, BlizzardBlue, Blue; can you clarify us? thx! - Gaetan 2013/11/8 Daniel Micay danielmi...@gmail.com On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager jfa...@gmail.com wrote: Can you speak a little to the practical differences between owned boxes and ~[T]/~str? How does the difference affect how I should use each? I wrote the section on owned boxes in the tutorial currently in master, so I would suggest reading that. It's very rare for there to be a use case for an owned box outside of a recursive data structure or plugin system (traits as objects). The coverage in the tutorial of vectors/strings is not only lacking in depth but is also *incorrect*, so I understand why there's a lot of confusion about them. Vectors/strings are containers, and aren't connected to owned boxes any more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar didn't exist and we just had generic container literals, because it seems to end up causing a lot of confusion. ___ 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] About owned pointer
I think a clear paragraph on these cases (~ and ~[]) will help a lot the understanding of this subtlety... - Gaetan 2013/11/8 Daniel Micay danielmi...@gmail.com On Fri, Nov 8, 2013 at 3:46 AM, Gaetan gae...@xeberon.net wrote: // An exchange heap (owned) stringlet exchange_crayons: ~str = ~Black, BlizzardBlue, Blue; can you clarify us? thx! - Gaetan I suggest ignoring the string/vector section in the tutorial because it's misleading and in some places incorrect. I'll send in a pull request removing the incorrect information. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I agree - Gaetan 2013/11/8 Diggory Hardy li...@dhardy.name On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: I am not sure why Daniel says that a `~str` or `~[]` is not an owned box. I guess he's using the term in some specific way. I consider `~str` and `~[]` to be exactly the same as any other `~T` value in usage and semantics. They are allocated on the same heap, moved from place to place, and freed at the same time, etc. The difference between a type like `str` or `[T]` and other types is that `str` and `[T]` are actually a series of values: `u8` bytes and `T` values respectively. This entails a change in representation and is also the reason that one *must* use a pointer to refer to them, because the number of values is not known and hence the compiler can't calculate the size of the value. Note that we are to some extent evolving how we handle dynamically sized types like `str` and `[]`. Right now they are quite second class (you can't impl them etc) but that will change. Nonetheless, it will remain true that you can never have a *value* of type `str` or `[]`, but most always use a pointer (either `~[]` or `[]`). Also note that a type like `~[T]` is in fact going to be represented not as a single pointer but rather three pointers, thanks to work by Daniel in fact. What's wrong with sticking with convention here? E.g. C++'s `string` and `vectorT` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thinking of them as pointers). So why not consider `str` and `[T]` conglomerates of a fixed size containing the pointers (start, length and capacity or whatever) needed? Semantically it's the same while syntactically it's simpler. Slices will need new names of course, but I think the resulting decrease in confusion will be worth it. (D's developers tried to go the other way, with all arrays and slices being effectively copy-on-write slices, before realising that discrete array/slices types _were_ needed.) DH ___ 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] About owned pointer
Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
sorry for the confusion - Gaetan 2013/11/7 Robert Knight robertkni...@gmail.com Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? ~ does allocate on the heap. Without ~ you allocate on the stack. Regards, Rob. On 7 November 2013 10:03, Gaetan gae...@xeberon.net wrote: Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any average user-code (ie, not the rust compiler itself) will have a lot of ~var anywhere, let i=~5, ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ 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] Using libextra within libstd?
hello I'm new in the rust dev list, so sorry if the question has already been rised. But what is the reason to have 2 libraries std/extra? why not gathering all in a single std library? Thanks G. - Gaetan 2013/11/4 Brian Anderson bander...@mozilla.com On 11/03/2013 11:10 PM, Martin DeMello wrote: I've been looking at https://github.com/mozilla/rust/issues/6085 which seems like it should be fairly simple to fix, however, the proposed solution involves EnumSet from libextra. Is it possible to use stuff from libextra within libstd? It seems to me that it would set up a circular dependency, though that could just be my misunderstanding the rust compilation model. If it is possible, how would I do it? If not, what would be the proper fix for issue #6085? As others mentioned it's not generally possible, but just for curiosity's sake I'll point out that when running tests std *does* link to and use features from libextra. It's mind-bending and bad. When we decide that std absolutely can't live without features from extra, then those features get promoted to std. The bar is pretty high though. ___ 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] Using libextra within libstd?
ok I understand, it will be like python which I really like the modularity. I'm beginning to play a little with std::os as my first rust programming, trying to add missing methods, etc, and I think this should quite strategic to move to libextra and then to be splitted appart, this would solve this cyclic dependency. What do you think about it? - Gaetan 2013/11/4 Martin DeMello martindeme...@gmail.com How does this work without getting into a dependency loop at build time? martin On Mon, Nov 4, 2013 at 10:55 AM, Brian Anderson bander...@mozilla.com wrote: On 11/03/2013 11:10 PM, Martin DeMello wrote: I've been looking at https://github.com/mozilla/rust/issues/6085 which seems like it should be fairly simple to fix, however, the proposed solution involves EnumSet from libextra. Is it possible to use stuff from libextra within libstd? It seems to me that it would set up a circular dependency, though that could just be my misunderstanding the rust compilation model. If it is possible, how would I do it? If not, what would be the proper fix for issue #6085? As others mentioned it's not generally possible, but just for curiosity's sake I'll point out that when running tests std *does* link to and use features from libextra. It's mind-bending and bad. When we decide that std absolutely can't live without features from extra, then those features get promoted to std. The bar is pretty high though. ___ 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] This Week in Rust
+1 I just subscribed yesterday and I really appreciates this overview :) - Gaetan 2013/10/29 Jack Moffitt j...@metajack.im I just wanted to thank you for the This Week in Rust notes. I love reading them and I am sure that I am not the only one who appreciates the effort that you put into each one. +1! These are great. They are the easiest way for us on the Servo team to estimate how much work we'll need to do to upgrade. jack. ___ 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
