Re: [rust-dev] Rust Radio - an SDR framework
SDR is an EXCELLENT software design challenge to flex Rust's muscles (and expose latent bugs) ! On Thu, Sep 11, 2014 at 9:32 AM, Evan G eg1...@gmail.com wrote: This is so cool! SDR are awesome. On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie allen.wel...@gmail.com wrote: If anyone is interested in software defined radios, I'm starting a project called Rust Radio (very similar to GNU Radio). Take a look at https://github.com/awelkie/rustradio. It's still pretty new, but critiques and contributions are always welcome! ___ 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 -- -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
Re: [rust-dev] Migrating libs out of rust-lang/rust
[snip] 2. A status page [2] is provided to get a quick glance at the status of all officially supported repositories. The amount of infrastructure around keeping these repositories up to date will likely change over time, but this is the current starting point for automation. [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml [2]: http://buildbot.rust-lang.org/travis/travis.html So going forward... Where can we look in source / folders / files ... to see what is an officially supported repository and what is not ? Let's say I don't want to have to look at the Travis view for that info, but just look at source to figure this out. -- -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
Re: [rust-dev] Cargo multiple targets
The links for FAQ and Manifest Format on http://crates.io should be rearranged to be at the top of the homepage...instead of the bottom, in my opinion. On Wed, Jul 2, 2014 at 7:38 AM, Isak Andersson cont...@bitpuffin.com wrote: Hi! Wow I didn't know about the manifest page, I was under the impression that the docs were very lacking. But this is pretty great. Thanks a bunch that was super helpful! On Wed, Jul 2, 2014 at 2:09 PM, Vladimir Matveev dpx.infin...@gmail.com wrote: Hi, Isak! According to manifest documentation [1] you can specify crate type (dynamic or static lib or rlib) using crate_type option: [[lib]] … crate_type = [dylib, staticlib] The above configuration should build you both .a and .so files. [1]: http://crates.io/manifest.html, search for crate_type w/o quotes On 02 июля 2014 г., at 15:58, Isak Andersson cont...@bitpuffin.com wrote: Hi! Thanks for the reply! Apparently multiple targets does in fact work. Just that you can't rely on the default path anymore, so I had to add the path = ... to both the [[lib]] and [[bin]]. Not sure if this is a bug or not. However the library compiles as an rlib and I'm not sure how to change it to build a C library instead (a .a or .so on *nix or .lib I think on windows). Actually I'm not even sure how to make rustc build a C library so I guess that's what I will start looking at. On Wed, Jul 2, 2014 at 1:37 PM, Sebastian Gesemann s.gesem...@gmail.com wrote: On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote: Hello Rust folks! I am using Cargo and I am trying to specify mulitple targets in my Cargo.toml file. First of all is this even possible? ... [package] name = hmproof version = 0.1.0 authors = [ i...@houstonmedia.se ] [[bin]] name = hmwhoami [[lib]] name = proof (I also tried adding a path) path = src/proof.rs [dependencies.rust-http] git = https://github.com/chris-morgan/rust-http.git; I also tried putting the [[lib]] part after the dependencies part. The error I get is this: error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no such file or directory [...] Whiich doesn't make any sense at all to me. Why does it suddenly start looking in src/bin? According to http://crates.io/manifest.html the default path for a binary is src (if there is no other lib) and src/bin (if there is also a lib target). You should be able to override this with path = src/hmwhoami. Do I have to put my bin code in src/bin and my lib code in src lib or what? Currently, only a single lib per package is supported and it seems, judging by the document about the manifest format, that Cargo always looks for src/lib.rs for a library unless you override this using a path=something. As for how to tell Cargo to invoke rustc with the appropriate -L option: I don't know. HTH, sg ___ 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 -- -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
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
Hey Fantix, nice job ! By the way, if you really have time to spare...MQTT would also be a nice to have library...for the embeddable sensor domain guys. A bit about it here: http://clockwerx.blogspot.com/2014/06/whats-mqtt-and-how-can-you-use-it.html -- -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
Re: [rust-dev] Integer overflow, round -2147483648
I completely agree with Daniel in all points on this thread. (he aggressively states over and over his stance and the teams concerning the goals of Rust. The team has not deviated from their objective of the Rust model. Kudos.) I do not need compiler switches nor do I want them. I want the control defined in the code by me. Giving me that control for wrapping on/off for a scope is the way forward. Whatever the names end up being... +1 for wrapping on/off for a scope. Get 'er done. (and thanks for keeping my memory safe) On Tue, Jun 24, 2014 at 2:01 PM, Daniel Micay danielmi...@gmail.com wrote: On 24/06/14 02:34 PM, Daniel Micay wrote: You haven't explained how this is going to cause security issues in Rust, when the language is guaranteed to be memory safe outside of `unsafe` blocks. The `unsafe` blocks are low-level, performance critical code where unnecessary overflow checks are always going to be acceptable, so the feature has next to no value in terms of memory safety. s/acceptable/unacceptable/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] How to find Unicode string length in rustlang
Benjamin seems to say that folks won't read the docs and we need to make the syntax more helpful.. Kevin seems to say that we need to keep the syntax simple and just teach folks to read the docs. I think I would agree with both of them overall for a language design goal that Rust wants to meet ...and in that light... I would first and foremost improve the docs which probably caused Aravinda's original confusion...there's no mention of u8 in this doc search, for instance, for the method that Aravinda used in his example : http://doc.rust-lang.org/0.10/std/index.html?search=from_str -- -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
Re: [rust-dev] A few random questions
You can also read and search the docs and easily see the Implementors (and
even click on them to get more detailed documentation AND even have 1 click
access to the [src] ) :
http://doc.rust-lang.org/0.10/std/to_str/trait.ToStr.html
If you find the docs are lacking a bit, then let the maintainers know
(there is ongoing effort to improve the docs by the way...even a few newly
hired folks at Mozilla).
On Wed, May 28, 2014 at 8:23 PM, Sean McArthur smcart...@mozilla.comwrote:
On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky o...@eterevsky.comwrote:
3. It seems like almost any string operation requires as_slice().
Can't various string methods be also implemented for String?
When writing functions for others to use, you don't want to require them
to have a String, since that requires a heap allocation. It's free to go
from String to a slice, but not vice-versa. That said, there's been
whispers of making String implement Deref, as well passing as arguments to
autoderef, so you could pass a String and rustc would convert to a slice
for you.
5. Simple indexing doesn't work for vectors:
let a = vec![1, 2, 3];
println!({}, a[0]);
It's a bit surprising...
Known issue: https://github.com/mozilla/rust/issues/11875
6. impl ToStr for custom struct fails:
error: conflicting implementations for trait `std::to_str::ToStr`
note: conflicting implementation in crate `std`
Is it a bug? Is Show implicitly assumed for all struct's?
This is because ToStr is implemented for all Show implementations. You
can't implement ToStr, because if you then implemented Show, you'd have
conflicting implementations. #[deriving(Show)] on your structs is probably
all you want.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
-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
Re: [rust-dev] UTF-8 strings versus encoded ropes
Agreed with Patrick. This proposal should not be in std::str ... it can live somewhere else...but not there. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ On Thu, May 1, 2014 at 4:52 PM, Patrick Walton pcwal...@mozilla.com wrote: On 5/1/14 6:53 AM, Malthe Borch wrote: In Rust, the built-in std::str type is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes. Meanwhile, building on experience with Python 2 and 3, I think it's worth considering a more flexible design. A string would be essentially a rope where each leaf specifies an encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two bytes). This is too complex for a systems language with a simple library. 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] A small announcement for zinc, the bare metal rust stack
I would have named it ... oxide instead of zinc ;-) ... rust = iron oxide On Tue, Apr 22, 2014 at 1:50 PM, Brian Anderson bander...@mozilla.comwrote: This sounds very useful. Thanks for letting us know. On 04/22/2014 09:10 AM, Vladimir Pouzanov wrote: This is the project I've been tinkering with for a good number of weekends — zinc, the bare metal stack for rust is available at https://github.com/hackndev/zinc. I've just finished a major refactoring work for LPC1768 code, so STM32F4 is kind of broken yet, and LPC1114 is totally dropped, but I'll fix that soon. The current code supports GPIO operations, UART and SSP in SPI mode for NXP LPC1768, also featuring a driver for http://mbed.org/cookbook/mbed-application-board TFT LCD and for ILI9341-based TFT LCDs commonly found on ebay. My plan is to fix support for STM32F4, bring it to the level of NXP part and try to expand this to a small RTOS, which would be a nice demo of rust capabilities for embedded development. The code is licensed under Apache-2.0. There's no readme yet, but you can see the demo applications written with zinc here: https://github.com/hackndev/zinc/tree/master/apps. -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ 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 -- -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
Re: [rust-dev] Rust windows bots have transitioned to mingw-w64
LOL. OK, and I'll keep me fingers crossed. ;) On Fri, Apr 11, 2014 at 3:40 PM, Brian Anderson bander...@mozilla.comwrote: It turns out this was premature and the bots are still using the old toolchain. I'll keep working on it. On 04/10/2014 05:05 PM, Brian Anderson wrote: After a long time coming, the Rust windows bots are now running an up-to-date mingw-w64 toolchain. This was a very easy transition thanks to the efforts of our windows devs, including Vadim, Thad, and klutzy. The practical impact of this is that windows developers should prefer the mingw-w64 toolchain to the old mingw toolchain. This is the toolchain we will be supporting on Windows for the immediate future. I've updated the [windows instructions] and the [getting started] page slightly, but there's a lot of information there that I don't fully understand. I'd appreciate if some of the more experienced windows devs could go over them and make sure they are accurate. The next step will be to add 64-bit windows bots and snapshots. [windows instructions]: https://github.com/mozilla/rust/wiki/Using-Rust-on-Windows [getting started]: https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] About Rust programming language.
Much better 2nd response, Brian. More like a salesman. You want to pull them in ... not push them away :-) On Thu, Apr 10, 2014 at 2:01 PM, Brian Anderson bander...@mozilla.comwrote: Sorry for the curt response. The answer is that Rust is suitable for many of the same tasks as C. Thank you. Please do not have this discussion here. On 04/10/2014 11:58 AM, Brian Anderson wrote: Thank you for your interest, but this is not a constructive topic for this venue. On 04/10/2014 11:35 AM, Jason Long wrote: Hello Folks. How are you? I want to know something about Rust language and Is it C killer? I mean is that in the future is it a replacement for C? Cheers. ___ 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 -- -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
Re: [rust-dev] Rust windows bots have transitioned to mingw-w64
Ra Ra Ooo La La ! Good work team ! (looking forward to the 64-bit snapshots) On Thu, Apr 10, 2014 at 7:05 PM, Brian Anderson bander...@mozilla.comwrote: After a long time coming, the Rust windows bots are now running an up-to-date mingw-w64 toolchain. This was a very easy transition thanks to the efforts of our windows devs, including Vadim, Thad, and klutzy. The practical impact of this is that windows developers should prefer the mingw-w64 toolchain to the old mingw toolchain. This is the toolchain we will be supporting on Windows for the immediate future. I've updated the [windows instructions] and the [getting started] page slightly, but there's a lot of information there that I don't fully understand. I'd appreciate if some of the more experienced windows devs could go over them and make sure they are accurate. The next step will be to add 64-bit windows bots and snapshots. [windows instructions]: https://github.com/mozilla/ rust/wiki/Using-Rust-on-Windows [getting started]: https://github.com/mozilla/rust/wiki/Note-getting- started-developing-Rust ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] Rust automation downtime
Curious, Whole Mozilla moving ? or just some teams ? and why ? making room for others ? kicked out by grumpy landlord or mayor ? :-) On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson bander...@mozilla.comwrote: This weekend Mozilla's Mountain View office is moving, and along with it some of Rust's build infrastructure. There will be downtime. Starting tonight bors is not gated on the mac or android builders and those machines are turned off. Sometime this weekend other build machines, including the build master and bors, will be moved and things will stop working. The Monday triage email will be delayed. We'll sort everything out Monday. Sorry for the inconvenience. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] issue numbers in commit messages
Use a better graphical Git client ? (instead of Github itself) I personally just do my reviews through Gitk from my Git Bash install on Windows. Screenshot: Gitk.PNGhttps://docs.google.com/file/d/0B533WzlrxWraX1U5eDJ0S245ZVE/edit?usp=drive_web On Linux, you might be better suited with other graphical Git clients, just for your own browsing of auto-merges, etc. Here's a dated article (2012) that covers some of them: http://www.maketecheasier.com/6-useful-graphical-git-client-for-linux/ On Mon, Feb 17, 2014 at 9:34 PM, Palmer Cox palmer...@gmail.com wrote: If bors rewrites the commit messages, it means that if someone approves commit ABC, what actually gets merged will be commit XYZ. This seems potentially confusing to me and might also make it more difficult to start with a reviewed commit on Github, such as https://github.com/gentlefolk/rust/commit/37bf97a0f9cc764a19dfcff21d62384b2445dcbc, and then track back to the actually merged commit in the history. I'm also not 100% sure, but I think git might have some issues with it as well. If I do my work on a throwaway branch, after merging, will git know that the changes in that branch were merged? Or, will git require me to do a git branch -D to delete that branch? Are there other projects that rewrite commit messages before merging? It seems to me that the ideal case would be for Github to add a link on the commit view page back to the PR that merged that commit. I'd be concerned that if Github adds support for such a feature in the future that it might not work if we've re-written all of the commit messages in the meantime. -Palmer Cox On Mon, Feb 17, 2014 at 9:28 PM, Nick Cameron li...@ncameron.org wrote: You are right, it is about convenient access to the info, not the lack of info. What is problematic about bors rewriting commit messages and changing hashes? My workflow is to always work on throw away branches and merge back into master. Is it common to work on master and merge back on top of your PR? Or are there other problems with changing the hash? On Tue, Feb 18, 2014 at 3:22 PM, Palmer Cox palmer...@gmail.com wrote: The PR# and who reviewed it is already available in the merge commit and its already possible to take any arbitrary commit and to see which merge commit merged it into master. So, I don't see any benefit in changing anything about the merge commit. Unless I'm missing something, this isn't a question of information not being available; its a question of that information being inconvenient to get to. I think having bors rewrite the commit messages would be somewhat problematic since it would change all the hashes. So, I think the only solution would be to manually put the issue number into the messages. However, many PRs aren't related to issues. So, if some large percentages of commits are just annotated with no issue or the like, it seems to really impact the utility of this change. Thus, I think it would really have to be the PR# instead of an issue # since every commit is related to a PR. However, I think it isn't a zero impact procedure. I always right the changes I want to merge before opening the PR. So, when I'm making my changes, I don't know what the eventual PR# is going to be. Only after I open the PR with the commits already created, I find out the PR#. So, then I'd have to rewrite all of the commit messages and force push back into the branch to get the numbers right. Its not the worst thing in the world, but it is an extra few steps. So, I strongly agree that the current procedure for finding the github discussion is fairly unpleasant and I very much wish that Github had a button that would take me to the PR that merged it. However, I don't think there is a 100% consistent, zero impact workaround for that missing feature in Github. My vote would be to leave things as they are. A little scripting could improve the situation quite a bit, although it still won't be as nice as being able to click on a link in Github. -Palmer Cox On Mon, Feb 17, 2014 at 9:02 PM, Scott Lawrence byt...@gmail.comwrote: What about having bors place the hash of each commit merged into the auto-merge message? Then finding the PR, and any closed issues, consists of backwards-searching in git-log. (Having bors modify commit messages would probably cause major problems with hashes changing.) On Tue, 18 Feb 2014, Nick Cameron wrote: Adding a few chars to a commit is not onerous and it is useful. You may not want it now, but perhaps you would if you had it to use. _I_ certainly want it, and I think others would find it useful if it was there to use. On Tue, Feb 18, 2014 at 1:37 PM, Steve Klabnik st...@steveklabnik.com wrote: Yeah, I'm not into modifying every single commit, I basically only want what bors already (apparently) already does. -- Scott Lawrence ___ Rust-dev mailing list
Re: [rust-dev] RFC: New Rust channel proposal
On Thu, Jan 23, 2014 at 2:33 PM, Brian Anderson bander...@mozilla.comwrote: On 01/13/2014 10:15 PM, Liigo Zhuang wrote: People should rethink the Chan api that Chan::new() does not returns a value of type Chan (instead, a tuple), which is strange, and inconsistent with other Type::new(). Agree, though I haven't heard any great suggestions yet. The core problem is that there are three different entities involved: the sending end, the recieving end, and the thing that represents the entire channel, and they all need different names. The best I've heard is `pipe() - (Port, Chan)`, but I would rather call the whole thing a channel and have a different name for the sender. A good alias / synonym for a sender would be a transmitter. food for thought. -- -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
Re: [rust-dev] Debugging (rust 0.9) in Ubuntu via GDB
Eclipse also has a GDB plugin to assist with debugging.
http://wiki.eclipse.org/Linux_Tools_Project/GDB/User_Guide
On Mon, Jan 13, 2014 at 5:52 AM, John Mija jon...@proinbox.com wrote:
There is a web front-end for gdb to debug applications in Go, C and C++.
I'm supposed that it also could be used to debug Rust apps.
https://github.com/sirnewton01/godbg
El 13/01/14 07:42, Michael Woerister escribió:
Hi,
the `break` command can be a bit particular where function names are
concerned, especially when namespaces and generics are involved. The
correct full name of the shuffle method would be something like
`std::rand::TaskRng::shuffleint` (there is a seperate function for
every set of concrete type parameters, so `shuffleint` would be
different from `shufflef32`).
My recommendation here is to either
* set the breakpoint using line numbers: break prog.rs:7
* or use the `rbreak` command which takes a regular expression as
argument, that is, `rbreak shuffle` will match any function containing
the string shuffle in its name.
Don't be shy to ask further questions if you have any :)
-Michael
On 13.01.2014 00:13, Artella Coding wrote:
Suppose I have the following program :
**
//prog1.rs http://prog1.rs
use std::rand::{task_rng, Rng};
fn main() {
let names = [Alice, Bob, Carol];
for name in names.iter() {
let v = task_rng().shuffle(~[1,2,3]);
for num in v.iter() {
println!({:s} says: {:d}, *name, *num);
}
}
}
**
In previous versions of rust it was possible to put
a breakpoint on shuffle e.g.
One would first compile via :
rustc -Z debug-info prog1.rs http://prog1.rs
and then one could proceed to put a breakpoint on shuffle :
gdb ./prog1
(gdb) break shuffle
(gdb) run
However now it doesn't seem possible to put a breakpoint on shuffle.
Why is this? Thanks.
___
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
--
-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
Re: [rust-dev] RFC: A 30 minute introduction to Rust
I think Mozilla just found their new hire for documentation writing ! Excellent Steve ! That's the kind of story and style that makes learning actually fun for folks; By giving good examples and analogies to foreign concepts along the way (books). -- -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] Fast inverse square root in Rust
Where is the fast inverse square root function in Rust ? http://en.wikipedia.org/wiki/Fast_inverse_square_root Anyone know if this semi-accurate function is at a hardware level and built in to Intel chipsets since MMX ? How does this affect LLVM and Rust compilation on 64 bit ? Thanks in advance, -- -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
Re: [rust-dev] Fast inverse square root in Rust
Is that implemented through LLVM at http://llvm.org/docs/doxygen/html/TargetTransformInfo_8h_source.html 00265 /// haveFastSqrt -- Return true if the hardware has a fast square-root00266 /// instruction.00267 virtual bool haveFastSqrt http://llvm.org/docs/doxygen/html/classllvm_1_1TargetTransformInfo.html#a01138d480dc0f9e11216e65d676a5bb9(Type http://llvm.org/docs/doxygen/html/classllvm_1_1Type.html *Ty) const; How does that pass from Rust ??? On Sun, Jan 12, 2014 at 11:51 AM, Owen Shepherd owen.sheph...@e43.euwrote: The Fast inverse square root is no longer fast. SSE implements accurate square root which is faster. Owen Shepherd http://owenshepherd.net | owen.sheph...@e43.eu On 12 January 2014 17:31, Carter Schonwald carter.schonw...@gmail.comwrote: http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html On Sunday, January 12, 2014, Thad Guidry wrote: Where is the fast inverse square root function in Rust ? http://en.wikipedia.org/wiki/Fast_inverse_square_root Anyone know if this semi-accurate function is at a hardware level and built in to Intel chipsets since MMX ? How does this affect LLVM and Rust compilation on 64 bit ? Thanks in advance, -- -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 -- -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
Re: [rust-dev] Properly licensing Rust documentation and wiki
I touched the wiki. All Thad Guidry edits are Public Domain, of course. Or MIT/ASL2 license if you so desire. On Fri, Jan 10, 2014 at 9:44 PM, Brian Anderson bander...@mozilla.comwrote: Hey. Time for more legal stuff. Per https://github.com/mozilla/rust/issues/5831the licensing of our documentation is not clear. Like all things Rust we want to make our doc license as permissive as possible, so after getting some legal advice here is what I intend to do: * Rust documentation will be MIT/ASL2 licensed like everything else. * Add the license as a *footer* to existing in-tree documentation, under the argument that it is already licensed according to the same terms as the rest of the repo. * Gather new statements from wiki contributors asserting that they contrtibuted under the MIT/ASL2, as we did when we relicensed Rust. * Put the license as footers on all pages of the wiki. For the most part this should not affect anybody, though if you've ever touched the wiki you may recieve an email from me about this in the future. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] RFC: Future of the Build System
Best Reason ever for a Rust Build System = You Prove Rust Itself. So get hacking on a Rust Build System. -- -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
Re: [rust-dev] Porting rust to DragonFlyBSD
I am VERY interested in the support of this platform, DragonFlyBSD. Which is a great Systems OS in and of itself. Thanks for your future efforts on it, Michael ! (BTW, in particular, I am interested in access to the HAMMER File System on DragonFlyBSD to begin my experiments) On Tue, Jan 7, 2014 at 10:10 AM, Alex Crichton a...@crichton.co wrote: The snapshots themselves are all static binaries in the sense that they have no dynamic rust dependencies and only the necessary system dependencies. Rustc does not generate 0-dependency static binaries right now that depend on libstd (as that would involve rewriting libc and writing a syscall interface for all platforms). When porting to a new architecture, the general idea is to add support in the compiler and standard libraries, then use cross compilation from a supported platform to generate a snapshot for the target platform, then take the snapshot and bootstrap on the target platform. A new platform hasn't shown up in awhile, but this sounds pretty cool! On Tue, Jan 7, 2014 at 7:37 AM, Michael Neumann mneum...@ntecs.de wrote: Hi there, At the moment rust only supports Linux/FreeBSD/Windows/MacOSX. I'd like to be able to compile it on DragonFlyBSD [1]. I am trying to get the FreeBSD stage0/bin/rustc to run on DragonFly, yet with no success. Is it possible to generate a static rustc binary somehow? Or what in general is the procedure to port rustc to a different platform? Regards, Michael [1]: http://www.dragonflybsd.org/ ___ 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 -- -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
Re: [rust-dev] on quality success
Denis, Long form email is not the best method of communication or to express your design thoughts...I would suggest a blog link instead. Also note that Patrick has asked the community numerous times... Give specific alternative solutions of where you think Rust has made design mistakes, preferably in bullet form so they can be addressed one at a time. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Thoughts on the Rust Roadmap
Libraries will follow a set of stability level guarantees that vary on a module-by-module basis. Stability encompasses both API level stability and semantic stability: if the semantics change in a way that is likely to break code, we'll introduce a new API instead of modifying a stable one. Patrick +1 DEPRECATION, instead of removal. Thad likes this. -- -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
Re: [rust-dev] How to search the mailing list archives
Actually, you do not have to change the article to thread...instead, just CLICK on the Subject and you get the full thread discussion view. Thanks for the tip Benjamin ! (search at the bottom ? whatever. everyone is copying Firefox these days. :-) ) On Tue, Dec 3, 2013 at 9:11 PM, Benjamin Striegel ben.strie...@gmail.comwrote: Apparently even Brian doesn't know how to do this, so I figured I'd share this tip. The rust-dev mailing list is archived here: http://thread.gmane.org/gmane.comp.lang.rust.devel/ Use the search box at the bottom to search through the mailing list's archives since the beginning of time. When you click on a result, you will end up on a page like this: http://article.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst ...which is pretty terrible from a navigation standpoint. But in that URL you can manually change the article bit on the front to thread, to yield this: http://thread.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst ...which will let you easily browse a full conversation. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] Rust forum
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
Re: [rust-dev] Rust forum
Agreed with Martin. It is my Opinion, but it might not be a good answer for you. If the problem space is having a searchable mailing list archive... I think we already have that in place, Right Brian ? On Tue, Dec 3, 2013 at 4:01 PM, Martin DeMello martindeme...@gmail.comwrote: keeping up with email is a lot easier than pretty much everything else, though. the solution to keeping old messages around is mirroring the mailing list to a searchable archive, not moving to a forum en masse and sacrificing ease-of-conversation for ease-of-recall. martin On Tue, Dec 3, 2013 at 1:58 PM, Gaetan gae...@xeberon.net wrote: 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 -- -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
Re: [rust-dev] Removing some autoref magic
may mutate `a`, while: let mut a = ~[y]; push(a, b); will *not* mutate `a`. Do others have the same expectation? But isn't there a missing context there ? That 'a' does not necessarily have to be mutable globally ? But could be constrained... only in the defined functions, or...traits...or ? -- -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
Re: [rust-dev] Rust docs
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
Re: [rust-dev] The future of M:N threading
Great ! Glad to hear that the plan is to support both use cases by abstracting M:N and 1:1 eventually. That will go a long way towards my later experiments with ETL (extract, transform, load) under various OS's and multi-core architectures using parallel task flow (I still don't know what I will call the flow type...lolol) On Wed, Nov 13, 2013 at 11:50 PM, Brian Anderson bander...@mozilla.comwrote: Thanks for the great reply, Alex. This is the approach we are going to take. Rust is not going to move away from green threads; the plan is to support both use cases in the standard library. On 11/13/2013 10:32 AM, Alex Crichton wrote: The situation may not be as dire as you think. The runtime is still in a state of flux, and don't forget that in one summer the entire runtime was rewritten in rust and was entirely redesigned. I personally still think that M:N is a viable model for various applications, and it seems especially unfortunate to just remove everything because it's not tailored for all use cases. Rust made an explicit design decision early on to pursue lightweight/green tasks, and it was made with the understanding that there were drawbacks to the strategy. Using libuv as a backend for driving I/O was also an explicit decision with known drawbacks. That being said, I do not believe that all is lost. I don't believe that the rust standard library as-is today can support *every* use case, but it's getting to a point where it can get pretty close. In the recent redesign of the I/O implementation, all I/O was abstracted behind trait objects that are synchronous in their interface. This I/O interface is all implemented in librustuv by talking to the rust scheduler under the hood. Additionally, in pull #10457, I'm starting to add support for a native implementation of this I/O interface. The great boon of this strategy is that all std::io primitives have no idea if their underlying interface is native and blocking or libuv and asynchronous. The exact same rust code works for one as it does for the other. I personally don't see why the same strategy shouldn't work for the task model as well. When you link a program to the librustuv crate, then you're choosing to have a runtime with M:N scheduling and asynchronous I/O. Perhaps, though, if you didn't link to librustuv, you would get 1:1 scheduling with blocking I/O. You would still have all the benefits of the standard library's communication primitives, spawning primitives, I/O, task-local-storage etc. The only difference is that everything would be powered by OS-level threads instead of rust-level green tasks. I would very much like to see a standard library which supports this abstraction, and I believe that it is very realistically possible. Right now we have an EventLoop interface which defines interacting with I/O that is the abstraction between asynchronous I/O and blocking I/O. This sounds like we need a more formalized Scheduler interface which abstracts M:N scheduling vs 1:1 scheduling. The main goal of all of this would be to allow the same exact rust code to work in both M:N and 1:1 environments. This ability would allow authors to specialize their code for their task at-hand. Those writing web servers would be sure to link to librustuv, but those writing command-line utilities would simply just omit librustuv. Additionally, as a library author, I don't really care which implementation you're using. I can write a mysql database driver and then you as a consumer of my library decided whether my network calls are blocking or not. This is a fairly new concept to me (I haven't thought much about it before), but this sounds like it may be the right way forward to addressing your concerns without compromising too much existing functionality. There would certainly be plenty of work to do in this realm, and I'm not sure if this goal would block the 1.0 milestone or not. Ideally, this would be a completely backwards-compatible change, but there would perhaps be unintended consequences. As always, this would need plenty of discussion to see whether this is even a reasonable strategy to take. On Wed, Nov 13, 2013 at 2:45 AM, Daniel Micay danielmi...@gmail.com wrote: Before getting right into the gritty details about why I think we should think about a path away from M:N scheduling, I'll go over the details of the concurrency model we currently use. Rust uses a user-mode scheduler to cooperatively schedule many tasks onto OS threads. Due to the lack of preemption, tasks need to manually yield control back to the scheduler. Performing I/O with the standard library will block the *task*, but yield control back to the scheduler until the I/O is completed. The scheduler manages a thread pool where the unit of work is a task rather than a queue of closures to be executed or data to be pass to a function. A task consists of a stack, register
Re: [rust-dev] Rust docs
Corey, Could we get that comments/feedback ability into the tutorial easily ? I agree that would be a good start in improving things. On Thu, Nov 14, 2013 at 9:38 AM, 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 -- -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
Re: [rust-dev] Danger of throwing exceptions through Rust code
In awe, Niko does a fantastic job of breaking things down. Give that guy a raise already. ;) And he brings the most important point of all in this discussion. Sometimes authors care and sometimes they don't Maybe the important distinction is how the author wraps the library, to bring about better failure semantics, regardless if the author needs them or not, at least they are available to care about or not ? -- -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] RosettaCode.org and Color of a Screen Pixel
Curious if Rust has a way to get the Color of a Screen Pixel yet ? http://rosettacode.org/wiki/Color_of_a_screen_pixel -- -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
Re: [rust-dev] Please simplify the syntax for Great Justice
From the outside looking in... I do not see anything preventing Greg from producing many macros or an entire syntax sub-system to emulate and empower him with any sugary languages that he might prefer or desire. It is just going to be quite a bit of work for him, but he could do it himself, if we wanted to turn Rust's syntax into something closer to Type Clojure or create a DSL. Is that not true ? On Mon, Nov 11, 2013 at 3:28 PM, Corey Richardson co...@octayn.net wrote: On Mon, Nov 11, 2013 at 4:07 PM, Greg g...@kinostudios.com 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. My point is that the familiar syntax *is* a feature. What simplifications do you propose? I think everyone is mostly happy with the syntax at this point, so your proposed changes and justification are going to be very pursuasive, and followed by a PR, for there to be a chance of them being accepted. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] Abandoning segmented stacks in Rust
Bill, memory is cheap. On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers bill_my...@outlook.com wrote: The advantage of segmented stacks is that blocked tasks only take up as much memory as they actually need to store state, so that for instance a network server can use a task for each connection, and still only use, say, 64 bytes per connection if that's possible instead of the number of stack pages that got allocated for previous computation (assuming an extreme version that allocates a stack segment on every call). However, there is another approach that can replace segmented stacks for that purpose, namely having the compiler automatically transform blocking functions to instead return a future (with limited lifetime). This means that segmented allocation only happens for functions that indirectly perform I/O and only allocates the exact amount of memory needed to retain state that must persistent across the blocking I/O operation, while other functions execute normally using traditional stacks. The simplest example of this feature is async/await in C# 5, and Scala has a delimited continuation passing transformation that can be used to do the same thing. Has this been considered for Rust? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -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
Re: [rust-dev] (no subject)
For my data experiments, I would rather like to see an LZ4 implementation https://code.google.com/p/lz4/ (a lossless, very, very, very, very, very, very, very, very fast decompression, with same compression - the very's are dependent on how many cpu cores you have :-) ) and it's BSD licensed. -- -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
Re: [rust-dev] Rust on Xen
THIS Anvil ? -- http://anvil.readthedocs.org/en/latest/topics/summary.html On Wed, Oct 23, 2013 at 8:32 PM, Brian Anderson bander...@mozilla.comwrote: On 10/23/2013 07:59 AM, Dan Cristian Octavian wrote: has there been any discussion about this recently? is there any issue associated with it? How smooth is tackling the problem of making unikernels out of rust code at the moment, given the state of the runtime? Not any further discussion along these lines, no. We saw Anil at OSCON and continued to agree that Rust would be great for this, but have not taken any steps. As Steve said though, a number of people are pursuing OS development in Rust. __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mozilla hiring a research engineer to work on Rust
And it looks like your still hiring for that LLVM Compiler engineer as well ! https://careers.mozilla.org/en-US/position/o3VZWfwD On Tue, Oct 22, 2013 at 6:40 PM, Brian Anderson bander...@mozilla.comwrote: Dear Rusties, Mozilla is going to hire another engineer to work on Rust! As we head toward Rust 1.0 we are looking for a motivated individual with serious chops to help us grind through the remaining blocking bugs. Enthusiasm for Servo will also be looked upon with great favor. See all the gory details here: https://careers.mozilla.org/**en-US/position/oMiEXfwphttps://careers.mozilla.org/en-US/position/oMiEXfwp I look forward to reading all those lovely applications. Regards, Brian __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Library for reading/writing Zip files
If an LZO library is not done already, that would be a good next step. -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] average function
Apparently, the version of Scott Lawrence is the fastest one, unless I made a mistake. Longest code (and simplest to understand code)... FTW ! :) (as usual) -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] average function
wait a sec.. your cheating in the benchmark... Why did you clone() the array for theirs and not Lawrence's ? See here: https://gist.github.com/qznc/6704053#file-benchmark-L76 On Wed, Sep 25, 2013 at 4:07 PM, Thad Guidry thadgui...@gmail.com wrote: Apparently, the version of Scott Lawrence is the fastest one, unless I made a mistake. Longest code (and simplest to understand code)... FTW ! :) (as usual) -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Problems with direct download of stage0 tarball
bah !! found my problem... had the extra /dl/ in the path. ignore this thread. :) On Tue, Sep 24, 2013 at 10:43 AM, Thad Guidry thadgui...@gmail.com wrote: I cannot seem to download this tarball, for some reason: http://static.rust-lang.org/stage0-snapshots/dl/rust-stage0-2013-09-23-348d844-winnt-i386-7988b58a9530a4ac0688ec978e9124c5db56717c.tar.bz2 ??? -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Minimal raytracer
You think Rust (or any of them) is slow ? Try raytracing by hand. :) On Tue, Sep 24, 2013 at 5:20 PM, Kevin Ballard ke...@sb.org wrote: I ran them myself. Incidentally, the Rust version is absurdly slow if I don't specify an optimization level. Here's what I got: Clang (-O3): 7.99s real Go (improved version): 9.68s real Go (original version): 16.73s real Rust (--opt-level=3): 13.03s real (I ran each case 3 times and took the median) So if we discard the algorithmically-improved Go, then we get 1) C++: 7.99s 2) Rust: 13.02s 3) Go: 16.73s I'm curious as to what difference using gccgo would make, but I didn't try (as I don't have GCC). -Kevin On Sep 24, 2013, at 2:48 PM, Huon Wilson dbau...@gmail.com wrote: On 25/09/13 04:13, Tim Kuehn wrote: To make it a fair fight, I converted the Go and C++ versions to trace Rust instead. These are my results on my Macbook Pro: === RUST === $ rustc -O bin.rs $ time ./bin rrays.ppm real 0m14.472s user 0m14.102s sys 0m0.365s === GO === $ go build main.go $ time ./main grays.ppm real 0m13.928s user 0m13.914s sys 0m0.020s === C++ === $ gcc -O crays.cpp $ time ./a.out crays.ppm real 0m10.800s user 0m10.794s sys 0m0.005s === RANKINGS === 1) C++ : 10.8s 2) Go : 13.9s 3) Rust : 14.5s This surprises me a lot (the fact that Go is (1) faster than Rust, (2) it's only 20% slower than C++, compared to 150+% originally), so I investigated, and found that the Go is cheating with an algorithmic improvement: https://github.com/kid0m4n/gorays/commit/249f229ba8c769c38d7dc018acfdf29cc86d6e43 If it's possible, could we re-run the benchmarks with the commit before that? Huon ___ 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 -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
Did you have a use case or situation in mind where you thought CUR should timeout? Jason No situation, I also think CUR should wait forever for the same reasons. Just curious, thanks for explaining ctrl-c regarding SIGINT, makes sense. -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Windows Users can build Rust properly again !
So, in my experiments tonight... I had to have the following copied into stage0/bin in order to build with mingw32 (gcc 4.8.1) Older libstdc++-6.dll which I got from here: http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.6.2-1/libstdc%2B%2B-4.6.2-1-mingw32-dll-6.tar.lzma/download AND libpthread-2.dll (which I created by copying renaming pthreadGC2.dll ) ... and now it builds just fine with i686-pc-mingw-32. I also agree with klutzy that we should bundle them for now. (and will enjoy getting a Clang build version to work from stage0 + whenever we can muster that origami) On Fri, Sep 20, 2013 at 12:49 AM, klutzy klutzytheklu...@gmail.com wrote: I wonder if we should just bundle runtime libraries with the stage0 snapshot in the future? I think we should bundle them: https://github.com/mozilla/rust/issues/9252 On Thu, Sep 19, 2013 at 7:16 AM, Vadim vadi...@gmail.com wrote: Okay, looks like my mingw 4 fix went in last night. Here's my personal recipe for setting up mingw: 1. Download and install mingw-get 2. Install the required packages. One can do this in GUI, but I prefer the command line, as it's less ambiguous: mingw-get install mingw-developer-toolkit mingw-get install mingw32-base mingw-get install mingw32-gcc-g++ mingw-get install mingw32-libpthreadgc mingw-get install msys-wget 3. Install GIT and Python, make sure they are on the PATH 4. In MSYS shell: ../configure; make check-fast Until stage0 snapshot compiler has been rebuilt with new mingw, stage0 compilation will fail because latest mingw has wrong versions of the runtime libraries that rustc depends on. So: 5.. Get old versions of these dlls: mingw-get upgrade g++4.6 mingw-get upgrade libpthread=2.8.0-3 6.. Copy libgcc_s_dw2-1.dll, libstdc++-6.dll and libpthread-2.dll from %mingw%\bin into %build%\i686-pc-mingw32\stage0\bin. 7. Roll mingw back to the latest: mingw-get upgrade 8.. make check-fast I wonder if we should just bundle runtime libraries with the stage0 snapshot in the future? Vadim On Mon, Sep 16, 2013 at 6:33 PM, Alex Crichton acrich...@mozilla.com wrote: Hey guys, so we're gonna hold off on upgrading the windows builders until we're 100% sure that we won't bork them with a mingw upgrade. What I think that we can do, on the other hand, is: 1. Land Vadim's patch onto master 2. I spin up a clean windows vm (need to do that anyway) 3. Could you guys send me a list of instructions to build rust on the most recent mingw? 4. Once verified, and possible bugs fixed, we can go upgrade the builders and documentation about mingw Ideally the build instructions would be: A. Acquire mingw. B. Acquire relevant gcc version 4.X C. ./configure make It'd be awesome to keep it that simple, and it seems that your patches would have eliminated the need for patching system files? How does that sound to you guys? On Sep 16, 2013, at 6:20 PM, Vadim vadi...@gmail.com wrote: -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
Does it HAVE to be a single typed char seen on the English 101 keyboard ? History Lesson: The industry in the very early, early days of printing, storing, and processing characters, both English and non-English, came up with a solution around the use of Control Characters. ASCI Char 1 is known as Start Of Header, or abbreviated SOH. ASCII Char 2 is known as Start of Text, or abbreviated STX. ASCII Char 3 is known as End of Text, or abbreviated ETX. It got me thinking of how various industries to this day still use Start of Text and End of Text... what we are discussing as enclosing a String verbatim. Many data operations that I perform with conversion of string fields are actually done by first wrapping with Control Chars [1] to enclose the String LITERALLY. Apple's Enterprise Partner Feed is an example that uses such basic Control Chars to separate fields and interestingly uses multibyte EOL Control Chars to retain even unicode contents (Foreign Language strings, that use quotes of a different nature at times [2] and that sometimes appear in its fields and that need to be retained inside a database field as well.) I am wondering if doing something similar to that the industry does with using Control Chars to represent a STX or ETX would not be even wiser to subplant String Literal ? i.e. do not reinvent the fast spinning wheel that also has built-in never go flat technology. :) [1] http://www.theasciicode.com.ar/ascii-control-characters/start-of-text-ascii-code-2.html [2] http://en.wikipedia.org/wiki/Non-English_usage_of_quotation_marks Thoughts ? -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Windows Users can build Rust properly again !
Good Job on documenting the build steps, Dandy ! Closer and closer we get
to flawless building on Windows.
On Mon, Sep 16, 2013 at 1:51 AM, Aaron Dandy aaron.da...@live.com wrote:
Klutzy helped me through a bunch of issues tonight and I am now building
stage 2 from HEAD using GCC 4.8. I put the procedure I used up on the
GitHub wiki for others to try and also linked it from the main getting
started page:
https://github.com/mozilla/rust/wiki/Note-Building-Rust-Before-0.8-on-Windows-Systems
.
Huge thanks for Klutzy helping me out.
Aaron@GIR /c/projects/rust/i686-pc-mingw32/stage2/bin
$ rustc.exe hello.rs
Aaron@GIR /c/projects/rust/i686-pc-mingw32/stage2/bin
$ hello
Hello, world.
Date: Sun, 15 Sep 2013 14:33:41 +0900
From: klutzytheklu...@gmail.com
To: vadi...@gmail.com
CC: rust-dev@mozilla.org
Subject: Re: [rust-dev] Windows Users can build Rust properly again !
The error is due to abi change of win32 gcc. reported here:
https://github.com/mozilla/rust/issues/9205
On Sat, Sep 14, 2013 at 4:52 PM, klutzy klutzytheklu...@gmail.com
wrote:
I've finished `make` on gcc 4.8.1, but `make check-fast` failed:
task unnamed failed at 'assertion failed: `(left == right)
(right == left)`
(left: `t_317::TwoU64s{one: 98784247808u64, two: 257698037760u64}`,
right: `t_317::TwoU64s{one: 22u64, two: 94489280535u64}`)',
C:\home\stone\rust-vanilla\src\test\run-pass\extern-pass-TwoU64s-ref.rs:27
make: ***
[i686-pc-mingw32/test/run_pass_stage2_driver-i686-pc-mingw32.out]
Error 101
I previously met this when I tested on mingw-w64/32bit.
(https://github.com/mozilla/rust/issues/8996)
Seems like the failure is related to recent gcc.
On Sat, Sep 14, 2013 at 3:35 PM, klutzy klutzytheklu...@gmail.com
wrote:
some more explanation:
#include fenv.h causes /lib/gcc/mingw32/ver/include/c++/fenv.h to
be included.
The header contains:
#include bits/c++config.h
#if _GLIBCXX_HAVE_FENV_H
# include_next fenv.h
#endif
where bits/c++config.h is at
/lib/gcc/mingw32/ver/include/c++/mingw32.
However, for some reason (I don't know), they removed `#define
_GLIBCXX_HAVE_FENV_H 1` somewhere between 4.6.2 and 4.8.1.
so `#include_next fenv.h` does not occur, which is
`/include/fenv.h`. It contains some definitions e.g. `FE_ALL_EXCEPT`.
On Sat, Sep 14, 2013 at 3:25 PM, klutzy klutzytheklu...@gmail.com
wrote:
I've solved it some minutes ago :)
klutzy at
/path/to/mingw/lib/gcc/mingw32/ver/include/c++/mingw32/bits/c++config.h:
klutzy there is #define _GLIBCXX_HAVE_FENV_H 1 in 4.6.1's header
klutzy but there isn't [such #define] in 4.8.1 header.
klutzy this causes /include/fenv.h not included when llvm does
#include fenv.h
The c++config.h has such lines:
/* Define to 1 if you have the fenv.h header file. */
/* #undef _GLIBCXX_HAVE_FENV_H */
I added `#define _GLIBCXX_HAVE_FENV_H 1` at the file directly, and it
works. We can't recommend users to do this hack though.
On Sat, Sep 14, 2013 at 3:21 PM, Vadim vadi...@gmail.com wrote:
Yes, but we can't check this into Rust repo. Maybe it can be worked
around
by -DWSAPOLLFD somewhere in makefiles...
And just as a heads-up, these seems to be another problem,- with
LLVM:
http://sourceforge.net/p/mingw/bugs/2043/
Vadim
On Sep 13, 2013, at 9:16 PM, klutzy k klutzytheklu...@gmail.com
wrote:
Mingw added new winapi at mswsock.h:
#if (_WIN32_WINNT = _WIN32_WINNT_VISTA)
int WSAAPI WSAPoll(WSAPOLLFD, ULONG, INT);
#endif
but they forgot to add definition of WSAPOLLFD.
Someone submitted patch at
http://sourceforge.net/p/mingw/bugs/1980/
but seems like it's not on mainstream.
Anyway, we (including libuv) don't use the api. Removing the
codeblock helps
us.
On Fri, Sep 13, 2013 at 3:19 PM, Vadim vadi...@gmail.com wrote:
Hmm. Looks like mingw released a new version with gcc 4.8 and that
somehow
broke mswsock.h (though the file didn't change).
On Thu, Sep 12, 2013 at 6:56 PM, Thad Guidry thadgui...@gmail.com
wrote:
Doesn't work...
Errors regarding libuv and mswsock...
http://pastebin.mozilla.org/3038909
On Thu, Sep 12, 2013 at 5:06 PM, Vadim vadi...@gmail.com wrote:
Hi Brian,
Actually, I would argue that these changes *should* be made before
0.8
release in order to smoothen the path of people who will install
0.8 to try
it out.
Regarding the work to be done, as far as I know all you need is:
1. Save libgcc_s_dw2-1.dll and libstdc++-6.dll from %mingw%\bin
2. mingw-get update
3. mingw-get upgrade
4. run %rust%\configure (not sure if actually needed, but won't
hurt)
5. make clean
6. make check, which will fail at building stage1 std crate
because
step 3 upgraded libgcc and libstdc++ and stage0 compiler
Re: [rust-dev] Rust's newest full-time Engineer
Congrats Alex ! And thanks for patching up LLVM build and moving things forward with Rust ! We still have over 1000+ things (issues) for you to steadily work on so, grab some tea. :-) On Mon, Sep 16, 2013 at 3:43 PM, Alex Crichton acrich...@mozilla.comwrote: Greetings rust-dev! I wanted to announce to everyone that today is my first day at Mozilla as an engineer working on Rust! I started using Rust last December for a project of mine, and once I got fed up with compiler errors I decided to try my hand at improving the compiler itself. The community was incredibly helpful in getting me on my feet contributing to rust, and it's been awesome seeing how rust and the community around it have evolved since I started working on it. I'm incredibly excited to have the opportunity to work on Rust with everyone who's been contributing, and I can't wait to help Rust reach 1.0 even faster. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] lib: Is anybody working on the datetime library?
Additionally, Be able to convert bya to mya ? http://en.wikipedia.org/wiki/Bya The short scale is now commonly used, btw... but also need to deal with this for conversions: http://en.wikipedia.org/wiki/Long_and_short_scales There should be a preference boolean for conversion output for short or long scale... especially concerning above a thousand million. That's enough to get you going with some wild ideas that Jodatime does not handle. On Fri, Sep 13, 2013 at 3:08 PM, Thad Guidry thadgui...@gmail.com wrote: One idea and use case for Paleontologists and Geologists coming over to Rust in droves... :-) Generically, just be able to handle simple Geologic addition and subtraction against an Epoch itself (reference date) http://en.wikipedia.org/wiki/Epoch_(reference_date) using known abbreviations. And additionally, store, understand, and output them: B.Y.B.P = Billion Years Before Present M.Y.B.P = Million Years Before Present On Fri, Sep 13, 2013 at 2:51 PM, Aaron Dandy aaron.da...@live.com wrote: I remember reading this article: http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html a while back and really appreciating date time time zone libraries. Also after reading news of the leap second triggering a bug on a bunch of systems I now question all assumptions I make about our representations of time. I can no longer say that a minute is 60 seconds long with a straight face. Next up I guess we programmers have a year 2038 problem to deal with too. This library will be a big deal to write but there thankfully there should be a lot of existing knowledge to learn from. -- Date: Fri, 13 Sep 2013 15:10:21 -0400 From: l...@debethencourt.com To: s...@scientician.net CC: rust-dev@mozilla.org Subject: Re: [rust-dev] lib: Is anybody working on the datetime library? Hello Bardur, Thank you so much for the reference resource of JSR-310 and its design docs. I looked over it briefly and it is indeed very valuable. It was listed in the wiki page, but the link was to the former home of it. I have updated it. Since nobody has claimed this module, I will start working on this module tomorrow Saturday. Is that OK? Please, please, I would love more comments and ideas. Will start asking for reviews once I have some code to show. Thanks, Luis On 13 September 2013 00:57, Bardur Arantsson s...@scientician.netwrote: On 2013-09-12 22:12, Luis de Bethencourt wrote: Hello everyone, I'm interested in helping with some module development. A good way to learn Rust by using it and help Rust at the same time. Of the wanted modules in this page: https://github.com/mozilla/rust/wiki/Libs I see that this page does have a link to design docs for JSR-310 which is probably a good bet as to a usable DateTime API design (for Java at least). I just thought I'd mention that the documentation for the nearly final (i.e. barring serious bugs) API has been released at: http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html Even if this is for Java, the design decisions about how the conepts of date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) would apply in any language. They are also all essential concepts when working seriously with date/time even though the distinctions may not appear so at first. (I should mention that the lead on the JSR-310 spec was also the author of JodaTime which gets much deserved credit by Java developers for bringing date/time manipulation on the JVM out of the dark ages of java.util.Date. JSR-310 is a slightly reworked/simplified version of that API, so it's a sort of what are the essentials? version of JodaTime.) Regards, ___ 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 -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] lib: Is anybody working on the datetime library?
One idea and use case for Paleontologists and Geologists coming over to Rust in droves... :-) Generically, just be able to handle simple Geologic addition and subtraction against an Epoch itself (reference date) http://en.wikipedia.org/wiki/Epoch_(reference_date) using known abbreviations. And additionally, store, understand, and output them: B.Y.B.P = Billion Years Before Present M.Y.B.P = Million Years Before Present On Fri, Sep 13, 2013 at 2:51 PM, Aaron Dandy aaron.da...@live.com wrote: I remember reading this article: http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html a while back and really appreciating date time time zone libraries. Also after reading news of the leap second triggering a bug on a bunch of systems I now question all assumptions I make about our representations of time. I can no longer say that a minute is 60 seconds long with a straight face. Next up I guess we programmers have a year 2038 problem to deal with too. This library will be a big deal to write but there thankfully there should be a lot of existing knowledge to learn from. -- Date: Fri, 13 Sep 2013 15:10:21 -0400 From: l...@debethencourt.com To: s...@scientician.net CC: rust-dev@mozilla.org Subject: Re: [rust-dev] lib: Is anybody working on the datetime library? Hello Bardur, Thank you so much for the reference resource of JSR-310 and its design docs. I looked over it briefly and it is indeed very valuable. It was listed in the wiki page, but the link was to the former home of it. I have updated it. Since nobody has claimed this module, I will start working on this module tomorrow Saturday. Is that OK? Please, please, I would love more comments and ideas. Will start asking for reviews once I have some code to show. Thanks, Luis On 13 September 2013 00:57, Bardur Arantsson s...@scientician.net wrote: On 2013-09-12 22:12, Luis de Bethencourt wrote: Hello everyone, I'm interested in helping with some module development. A good way to learn Rust by using it and help Rust at the same time. Of the wanted modules in this page: https://github.com/mozilla/rust/wiki/Libs I see that this page does have a link to design docs for JSR-310 which is probably a good bet as to a usable DateTime API design (for Java at least). I just thought I'd mention that the documentation for the nearly final (i.e. barring serious bugs) API has been released at: http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html Even if this is for Java, the design decisions about how the conepts of date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) would apply in any language. They are also all essential concepts when working seriously with date/time even though the distinctions may not appear so at first. (I should mention that the lead on the JSR-310 spec was also the author of JodaTime which gets much deserved credit by Java developers for bringing date/time manipulation on the JVM out of the dark ages of java.util.Date. JSR-310 is a slightly reworked/simplified version of that API, so it's a sort of what are the essentials? version of JodaTime.) Regards, ___ 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 -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry 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] Windows Users can build Rust properly again !
I have updated and added new steps (Step 5) that correctly install the
needed pthread libraries for Windows users of MinGW.
Rust now correctly compiles Stage0, Stage1, Stage2 out of the box
following the updated guide here:
https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust
The new package details for the pthread libraries provided from 'mingw-get
show' , for those interested are below:
Package: mingw32-libpthread-old Subsystem: mingw32
Components: dll
POSIX threading library for Win32
-
pthreads-w32 seeks to provide a freely available and high-quality
implementation of pthreads for Windows. Pthreads is an API for writing
multithreaded applications following the POSIX standard.
The mingw32-libpthread-old package provides the MinGW pthreads-w32
runtime dll associated with MinGW GCC 4.5.2 and older. Due to an
unfortunate naming choice, upgrading to newer GCC will also install the
newer, renamed pthreads-w32 DLLs, removing the old DLL. While the may
not affect the new GCC, threaded applications compiled using the older
compiler will break, as they will miss this runtime library. Therefore,
the old runtime library is provided here using a new package name:
mingw32-libpthread-old, so that it can be (re)installed parallel to the
new pthreads-w32 runtime libraries.
Package: mingw32-libpthreadgc Subsystem: mingw32
Components: dll
POSIX threading library for Win32
-
pthreads-w32 seeks to provide a freely available and high-quality
implementation of pthreads for Windows. Pthreads is an API for writing
multithreaded applications following the POSIX standard.
There are two mingw32 versions of the pthread-w32 runtime library: the
standard one, provided by this package, is called libpthreadgc but may
also be referred to as 'libpthread'. The non-standard one uses C++
exception handling, and is called libpthreadgce. (Note that the standard
library may be used successfully with C++ code; indeed, on most *nix
platorms the system pthreads implementation follows the behavior of
mingw32-libpthreadgc, and NOT the behavior of the 'GCE' version). We
recommend that most users rely on mingw32-libpthreadgc ('GC') and not
mingw32-libpthreadgce ('GCE').
The mingw32-libpthreadgc and mingw32-libpthreadgce packages provide the
two runtime libraries (most people need not install the 'GCE' one). The
associated mingw32-pthreads-w32 package provides the documentation for
the pthreads-w32 library, as well as the related development files. The
mingw32-libquserex package provides optional support for enhanced
standards conformance of the GCE runtime.
mingw32-libpthreadgc is a required component of the MinGW Compiler
Suite.
--
-Thad
Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry
Thad on LinkedIn http://www.linkedin.com/in/thadguidry/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Windows Users can build Rust properly again !
Yes, that's the game plan I have...and klutzy and Vadim getting the mingw-w64 toolchain working. On Thu, Sep 12, 2013 at 4:10 PM, Brian Anderson bander...@mozilla.comwrote: On 09/12/2013 12:39 PM, Thad Guidry wrote: Yeah, there should not be a reason anymore, if I am correct, to not have GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try also , and if it works, then we can close out (#8598https://github.com/mozilla/rust/issues/8598 ). (I also would like to get rid of the 4.5 downgrade needed) but that does need more testing from the core Rust team and others. It's something that Brian has been counting on me to help make happen, and Alex is also contributing to some of that effort by fixing various LLVM build issues that affect Windows Rust users as you mention in (#8598https://github.com/mozilla/rust/issues/8598 ). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878https://github.com/mozilla/rust/issues/5878 . Thanks for everybody's amazing contributions to our Windows support. If somebody makes the changes necessary to work with a newer toolchain then we will upgrade the bots. It's unlikely we can do this before 0.8 though, due in two weeks. I gather that some folks would like to switch to the mingw-w64 toolchain as well. Is that in the cards here? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Windows Users can build Rust properly again !
Doesn't work... Errors regarding libuv and mswsock... http://pastebin.mozilla.org/3038909 On Thu, Sep 12, 2013 at 5:06 PM, Vadim vadi...@gmail.com wrote: Hi Brian, Actually, I would argue that these changes *should* be made before 0.8 release in order to smoothen the path of people who will install 0.8 to try it out. Regarding the work to be done, as far as I know all you need is: 1. Save libgcc_s_dw2-1.dll and libstdc++-6.dll from %mingw%\bin 2. mingw-get update 3. mingw-get upgrade 4. run %rust%\configure (not sure if actually needed, but won't hurt) 5. make clean 6. make check, which will fail at building stage1 std crate because step 3 upgraded libgcc and libstdc++ and stage0 compiler needs them. 7. copy dlls saved in step 1 into %rust%\build\i686-pc-mingw32\stage0\bin 8. make check again, which should succeed this time Can somebody please verify that this works? Re mingw-w64: sort of works, however its' phtreads implementation seems to be buggyhttps://github.com/mozilla/rust/issues/8996#issuecomment-24292739. Also see this threadhttp://sourceforge.net/mailarchive/forum.php?thread_name=CAKEnbTNV4iDok-k9Gg-Wmr85utFPxLf4wmAabjJZ1WaCFVE5PQ%40mail.gmail.comforum_name=mingw-w64-public. I don't think we'll should migrate to it just yet. Vadim On Thu, Sep 12, 2013 at 2:10 PM, Brian Anderson bander...@mozilla.comwrote: On 09/12/2013 12:39 PM, Thad Guidry wrote: Yeah, there should not be a reason anymore, if I am correct, to not have GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try also , and if it works, then we can close out (#8598https://github.com/mozilla/rust/issues/8598 ). (I also would like to get rid of the 4.5 downgrade needed) but that does need more testing from the core Rust team and others. It's something that Brian has been counting on me to help make happen, and Alex is also contributing to some of that effort by fixing various LLVM build issues that affect Windows Rust users as you mention in (#8598https://github.com/mozilla/rust/issues/8598 ). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878https://github.com/mozilla/rust/issues/5878 . Thanks for everybody's amazing contributions to our Windows support. If somebody makes the changes necessary to work with a newer toolchain then we will upgrade the bots. It's unlikely we can do this before 0.8 though, due in two weeks. I gather that some folks would like to switch to the mingw-w64 toolchain as well. Is that in the cards here? ___ 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 -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] changing roles
Graydon, So what does not drain you ? What kicks you into high gear and keeps you salivating for more ? Many of us do not know you personally, and knowing a bit more about what really interests you, would open a few of our eyes on the list. (thanks for your efforts) On Fri, Aug 30, 2013 at 8:57 PM, Brian Anderson bander...@mozilla.comwrote: On 08/30/2013 05:05 PM, Graydon Hoare wrote: Hi, As I'm sure many of you who know me are aware, my role as technical lead on Rust has been quite draining over the years. Both to myself and to those I've worked with, it just isn't a great fit for me. In recognition of this, I am stepping aside to work elsewhere in the organization, and Brian will be assuming the role of technical lead of Rust. This news is bittersweet to say the least. The language that you invented and that I adore has come so very far under your leadership, and I hope that we can continue to build on the example you have set. It's been an enriching experience working with you, Graydon, and I wish you the best on your next project. -Brian __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustdoc_ng status: all items extracted
But why is cool coming up with so many search hits ? lololol On Mon, Aug 5, 2013 at 4:04 AM, Gareth Smith garethdanielsm...@gmail.comwrote: Great work, I like the search already. Thanks! On 05/08/13 06:53, Corey Richardson wrote: Hi all, I'm very excited to announce that rustdoc_ng now extracts and jsonifies crates completely in their entirety. Yay! Jordi has been doing some awesome work with the frontend, even adding a search. See http://seld.be/rustdoc/master/**index.htmlhttp://seld.be/rustdoc/master/index.html, for its current state. There's still a bunch of work to do, but all of it can be implemented with plugins. The cleaned crate is sendable, and in theory it should be generically encodable, but I don't know how to sling extra::serialize, so if anyone could lend a hand with that, that'd be cool. __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Java versus .NET style for acronyms in type names
On Mon, Aug 5, 2013 at 1:40 PM, Josh Leverette coder...@gmail.com wrote: Better even than the toggle mode caps style of gc/gcMut? (assuming mut is an abbreviation here, if it's an acronym, then it would be gc/gcMUT) But of course, looks are purely subjective. The key is objective comparison. Pure .NET style loses information about whether something is an acronym or an abbreviation, and that information can be useful. Josh, I would argue that the information is NOT lost... GcMut still means something somewhere, and the information of which is merely moved over to another, better place, in the form of documentation like http://seld.be/rustdoc/master/index.html...which can be easily searched and parsed itself...and linked to other data and the greater Semantic Web, tag and vocabulary systems, etc. -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Java versus .NET style for acronyms in type names
Everyone is already telling you. (And Brian is on a crusade for the cause already) Make distinguishing words in a long string...easier to interpret and read. Some of those words in a long string are abbreviations and acronymns. Deciding when its an abbreviation, an acronym, a suffix, affix, prefix, etc, etc... makes your brain work harder. We as programmers try to make lives, Easier. So, we should make it easier on ourselves as well. +1 for 1st uppercase letter on words, abbreviations, and acronyms. (.NET Style) On Sat, Aug 3, 2013 at 3:53 AM, Jens Nockert j...@nockert.se wrote: On 3 Aug 2013, at 03:28, Patrick Walton pwal...@mozilla.com wrote: Thoughts/straw poll? I prefer (and use) Java-style, I think it looks slightly better. But that's probably my ObjC background talking. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry 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] MPS investigation for Rust GC
REGARDING: - Graydon wants to investigate using the Memory Pool System as the Rust GC, rather than a bespoke one. The [MPS](http://www.ravenbrook.com/project/mps/) is a very mature and robust memory management library. Reading through and seeing one of the MPS creators initial design goals : The MPS was not designed for C++, but as a memory manager for dynamic language run-time systems. In fact, it was specifically designed not to require C++. ...instantly gained my respect for this system and its potential. -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry 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] Great summary of Windows Compiler Toolchain Options
I recently found the QT project has a great summary of the state of things for Windows users concerning Toolchains and Compiler choices supporting Exception Handling and their differences. http://qt-project.org/wiki/MinGW-64-bit -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 'in' for for loops and alloc exprs
Ian, Graydon, Community,
I am fairly NEW to programming in current languages at all... So I am a
great guinea pig for testing all these conversations about What would a
beginner to Rust...or even programming languages in general think about
this ? I personally think that dot notation is fine, and I have learned
why others, such as yourself, think that using dot notation might bring
some unfamiliarity in using it. It does not rub me the wrong way, and has
a functional order to it, but that is because my background way, way back
when, was only with functional languages.
In the end, folks have preferences, primarily based on what your used to
using that did not make your brain explode trying to understand it, and
made you fairly productive. In this case, I would hope that the language
design is decided by not a majority vote wins, but what represents a
pleasant taste in the mouth 90% of the time when programming Rust, no
matter their background. I would encourage the community to repeat good
designs, and stretch out against bad designs and debated language
preferences that folks have. You cannot please everyone, but a good goal
would be that 90% pleasant taste in the mouth. That's not trademarked,
so your free to use that Graydon, if necessary. :-)
So, back to the original thread subject you brought up...
Re-using in seems to also leave a pleasant taste in my mouth, simply
because I do not have a high preference, and am easily adaptable. I find
that if you can design a language that reads fairly well, WORKS AS
DOCUMENTED, and as a bonus is intuitive for 90% of the folks that read 50%
of the docs or less...then you've got a winning language design.
(and I would not hope that your sealing up the language just yet - since
there is no high visibility, in production system that is using it - but I
do understand the causal effects of introducing more keywords in this later
stage of design)
On Sat, Jul 27, 2013 at 11:40 AM, Ian P. Cooke i...@informatic.io wrote:
On Jul 27, 2013, at 10:48 , Zoltán Tóth zo1...@gmail.com wrote:
Then the coder can drop the pattern part without making the wording weird:
loop 10.times() { ... }
This syntax has always bugged me. I always read it as send the message
'times' to the object named '10' but 10 is an integer literal and integers
don't have behavior. The '10.times()' syntax makes it look to the reader
that he's observing a conversation with a number rather than a dictation of
the actions that 'self' is about to perform. I know Smalltalk and Ruby use
similar syntax but I feel like they're also wrong to do so. I like any of
the following:
for i in 1..10 {}
for i in range(10) {}
for _ in range(10) {} //if you don't care about the index of the iteration
for i in range(1, 20, 2) {}
all of which are more clear to me. Something as core as control flow
should have a simple syntax without object-oriented-looking, DSL-type
cleverness.
I don't intend to start a debate on the merit of any the various syntax
choices but this thread made me want to assure at least one
anti-'10.times()' opinion was heard :)
My motivation is actaully something different: I feel this order more
intuitive. I during coding generally like to be able to write the code in
the order that I think. When I want to write a loop, first I think about
that I want to iterate over some collection. Only after that do I think
about a suitable name for the loop_variable / iterator. I understand that
most programming languages use the pattern expr order and that
programmers are used to it, but I think to be be intuitive is more
important than to be similar, especially for a new language.
I do agree with this. SQL has a similar issue:
FROM t SELECT x, y, z
makes more sense (and as such can get more context-sensitive help) than
SELECT x, y, z FROM t.
Microsoft's Linq gets this order right IMO. In fact, Linq is pretty
awesome in general (
http://msdn.microsoft.com/en-us/library/vstudio/bb397906.aspx,
http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b ) although my
opinion is mostly academic there. Having language-level support for the
notion of a query would be incredibly useful to me (unifying local and
remote collections).
-ipc
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
-Thad
Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry
Thad on LinkedIn http://www.linkedin.com/in/thadguidry/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 'in' for for loops and alloc exprs
I also like 'do 10,times {' , since I likely would also use it to create
multiple copies (one after the other). A lazy sequence for my purposes
dealing with data generation.
Just to clarify, 'do 10.times {' would NOT allow launching multiple copies
in parallel, correct ? (that's reserved for Actor styles, etc, etc.) Just
simple repetition, as you say ?
On Thu, Jul 25, 2013 at 3:46 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
If we did that, we'd lose the ability to break or return, since 'do'
doesn't follow the for-style loop protocol.
I'm perfectly happy with that; the `times` method was never about complex
control flow, just simple repetition. `do 10.times {` is a delightfully
self-explanatory contract.
And just as evidence that `do` notation is useful beyond `spawn`:
$ git grep do .*{ -- *.rs | wc -l
2019
$ git grep do .*spawn -- *.rs | wc -l
274
we're likely to switch that to a macro call that passes
explicitly-captured arguments into a thunk struct that owns the explicit
captures
I don't remember seeing much of this idea in the meeting notes, but I do
remember seeing it mentioned in these blog posts (for those who want more
context):
http://smallcultfollowing.com/babysteps/blog/2013/05/30/removing-procs/
http://smallcultfollowing.com/babysteps/blog/2013/06/03/more-on-fns/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
-Thad
Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry
Thad on LinkedIn http://www.linkedin.com/in/thadguidry/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing codemap::spannedT
(spannedT predates having traits at all, so if there's a better way to approach this in current idioms, go right ahead) -Graydon Oooo, That's a good thing to know and have documented somewhere in the tutorial under Traits as a note. Can you add that Daniel ? I mean the idiom difference that Graydon is mentioning between the two. That would be good to have as a note in the tutorial. -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Incremental and generational GC
* Objects in the borrowed set are grayed before each incremental GC slice. *mutator* In a garbage-collectedhttp://www.memorymanagement.org/glossary/g.html#garbage.collection system, the part that executes the user code, which allocateshttp://www.memorymanagement.org/glossary/a.html#allocate objects http://www.memorymanagement.org/glossary/o.html#object and modifies, or *mutates*, them. For purposes of describing incremental garbage collectionhttp://www.memorymanagement.org/glossary/i.html#incremental.garbage.collection, the system is divided into the *mutator* and the *collector(2)http://www.memorymanagement.org/glossary/c.html#collector-2 *. These can be separate threads of computation, or interleaved within the same thread. The user code issues allocation requests, but the allocator code is usually considered part of the collector. Indeed, one of the major ways of scheduling the other work of the collector is to perform a little of it at every allocation. While the mutator mutates, it implicitly freeshttp://www.memorymanagement.org/glossary/f.html#free-1 storage http://www.memorymanagement.org/glossary/s.html#storage by overwriting referenceshttp://www.memorymanagement.org/glossary/r.html#reference . How will Rust deal with the mutator (the part that modifies user code and mutates it ) ? From a high level, will it be run as separate computation threads or within the same computation thread ? -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 64-bit Windows
Luqman and I found out today some interesting bits from the mngw guys on IRC... I'm going to continue documenting what I find on the Wiki page https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust under a new 64bit Windows building section. But here is the info so far: ( I set my MinGW64 path with a statement at the bottom of my MinGW/msys/1.0/etc/proifle with # Enable MinGW64 path export PATH=/c/mingw-builds/x64-4.8.1-win32-seh-rev1/mingw64/bin:/usr/local:$PATH ) From what we gathered the mingw-w64 toolchain installer [1] works well with the following easy installer settings: Install path is C:\mingw-builds Version: (to be determined what the max version of GCC to be that build correctly ? at 4.8.1 currently) Architecture: x64 Threads: win32 Exception: seh Build revision: (whichever latest for mingw-w64) This was based on our conversation with jon_y in mingw channel. [snip] jon_y: be aware that if you use the posix thread gcc, all your code will depend on the pthred dll whether you actually use pthreads or not jon_y: libgcc itself pulls in pthreads Thad: for our Rust (Windows) users...we'd choose win32 threads Thad: we instruct them on how to build it within the MinGW/Msys environment on our wiki jon_y: sure, the link I gave you will not support C++11 threads Thad: jon luqman says we don't need them. he would know. jon_y: ok Thad: so I think just the win32 thread with SEH for Win64 host is ideal Thad: thanks so so much jon_y: try to use the installer Thad: yeah a simple switch for that... easy jon_y: rather than pointing users to the link directly Thad: yeah, agree we will... I'll write it up and modify our step by step for Windows users today. Thanks ! jon_y: c++11 threads is the only reason you'd use the posix thread gcc on windpws jon_y: *windows jon_y: np Thad: Ill also make a note about that as well. [1] - http://sourceforge.net/projects/mingwbuilds (green button download installer.exe) On Thu, Jul 4, 2013 at 7:37 PM, James Miller aa...@aatch.net wrote: On 2013-07-04 10:02:29, Graydon Hoare wrote: On 13-07-03 11:32 PM, Lilly Matsson wrote: Hello! I recently made a post on Reddit (http://www.reddit.com/r/rust/comments/1hk25r/rust_on_64bit_windows_7/) asking about 64-bit Windows support, and kibwen urged me to post here to start some kind of discussion about the current state of 64-bit Windows support. So, what is the deal? What needs to be done to fully get 64-bit support for Windows? As I understand it, it has to do with LLVM. - Add a new target and host config in the makefiles. - Fiddle with the target-specific data layout string in librustc::back I'm currently working on stuff related to these two points at the moment, for the record. Basically moving the current target-handling stuff all to one place and making it run through a `~Target` trait object. This is based off of the related code in Clang currently. The code I currently have will _theoretically_ support every major platform, with there currently being code for MingW32, Cygwin and Win32 separately. From what I can tell, 64-bit MinGW is still considered to be MinGW32, just on a 64-bit architecture (This is based on the fact that the LLVM target triple code doesn't have a 'mingw64' entry). This means that when I'm done, it should be pretty easy to port to a new platform just by updating some build files and fixing any breakage. -- James Miller ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 64-bit Windows
Incidentally, the mingw guys plan to have x32 SEH (not just x64 SEH) working and available in 2014... something about letting a Borland patent having to expire... On Thu, Jul 4, 2013 at 8:25 PM, Thad Guidry thadgui...@gmail.com wrote: Luqman and I found out today some interesting bits from the mngw guys on IRC... I'm going to continue documenting what I find on the Wiki page https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust under a new 64bit Windows building section. But here is the info so far: ( I set my MinGW64 path with a statement at the bottom of my MinGW/msys/1.0/etc/proifle with # Enable MinGW64 path export PATH=/c/mingw-builds/x64-4.8.1-win32-seh-rev1/mingw64/bin:/usr/local:$PATH ) From what we gathered the mingw-w64 toolchain installer [1] works well with the following easy installer settings: Install path is C:\mingw-builds Version: (to be determined what the max version of GCC to be that build correctly ? at 4.8.1 currently) Architecture: x64 Threads: win32 Exception: seh Build revision: (whichever latest for mingw-w64) This was based on our conversation with jon_y in mingw channel. [snip] jon_y: be aware that if you use the posix thread gcc, all your code will depend on the pthred dll whether you actually use pthreads or not jon_y: libgcc itself pulls in pthreads Thad: for our Rust (Windows) users...we'd choose win32 threads Thad: we instruct them on how to build it within the MinGW/Msys environment on our wiki jon_y: sure, the link I gave you will not support C++11 threads Thad: jon luqman says we don't need them. he would know. jon_y: ok Thad: so I think just the win32 thread with SEH for Win64 host is ideal Thad: thanks so so much jon_y: try to use the installer Thad: yeah a simple switch for that... easy jon_y: rather than pointing users to the link directly Thad: yeah, agree we will... I'll write it up and modify our step by step for Windows users today. Thanks ! jon_y: c++11 threads is the only reason you'd use the posix thread gcc on windpws jon_y: *windows jon_y: np Thad: Ill also make a note about that as well. [1] - http://sourceforge.net/projects/mingwbuilds (green button download installer.exe) On Thu, Jul 4, 2013 at 7:37 PM, James Miller aa...@aatch.net wrote: On 2013-07-04 10:02:29, Graydon Hoare wrote: On 13-07-03 11:32 PM, Lilly Matsson wrote: Hello! I recently made a post on Reddit (http://www.reddit.com/r/rust/comments/1hk25r/rust_on_64bit_windows_7/ ) asking about 64-bit Windows support, and kibwen urged me to post here to start some kind of discussion about the current state of 64-bit Windows support. So, what is the deal? What needs to be done to fully get 64-bit support for Windows? As I understand it, it has to do with LLVM. - Add a new target and host config in the makefiles. - Fiddle with the target-specific data layout string in librustc::back I'm currently working on stuff related to these two points at the moment, for the record. Basically moving the current target-handling stuff all to one place and making it run through a `~Target` trait object. This is based off of the related code in Clang currently. The code I currently have will _theoretically_ support every major platform, with there currently being code for MingW32, Cygwin and Win32 separately. From what I can tell, 64-bit MinGW is still considered to be MinGW32, just on a 64-bit architecture (This is based on the fact that the LLVM target triple code doesn't have a 'mingw64' entry). This means that when I'm done, it should be pretty easy to port to a new platform just by updating some build files and fixing any breakage. -- James Miller ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Segmented stacks (was: IsRustSlimYet (IsRustFastYet v2))
On Windows there's a better way than DWARF or SJLJ to catch exceptions I learned today. (I have no idea what I am talking about, but here goes from what I read...) Windows uses it's own exception handling mechanism known as SEH. GCC supports SEH on Win64 (and has plans I think later for Win32?) More info in the answer here: http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh/15685229#15685229 and issues here: http://comments.gmane.org/gmane.comp.gcc.help/44153 On Thu, Jul 4, 2013 at 5:33 PM, Patrick Walton pwal...@mozilla.com wrote: On 7/4/13 12:58 PM, Daniel Micay wrote: You can create many threads with fixed stacks, they just start off using 4K instead of however much smaller our segmented stacks will be. A scheduler will just be more expensive than a regular lightweight task. The 15-100% performance hit from segmented stacks pushes Rust well out of the systems language niche. I think it does have to change if Rust plans on ever fitting in the niche that C, C++ and D do. I agree. The sole benefit of segmented stacks on modern OS's that lazily allocate pages is that, on 32-bit, you can avoid running out of address space with many tasks. This is counterbalanced by these disadvantages: 1. There is no way for the compiler or runtime to know ahead of time how much stack any given task will need, because this is based on dynamic control flow. 2. The consequence of overshooting (choosing a stack size that is too big) is that the benefit above is reduced. 3. The consequence of undershooting (choosing a stack size that is too small) is disastrous performance. In the limit, the performance degrades to something like what many Schemes and SML/NJ do, in that stack frames are malloc'd from the heap. Except that Scheme and SML/NJ have precise generational garbage collectors with bump allocators in the nursery, and we have C malloc(). Furthermore, stack segment allocation is the slow path in C malloc, because it's in a high storage class. So performance becomes abysmal in the slow path. Unlike systems like Erlang and Cilk, there is no way to relocate stack segments in Rust because of unmanaged interior pointers: Erlang could at least in theory correct its mistakes and keep stacks contiguous (although I don't know if the implementation does). So the best we can do is cache and hope for the best--but too much caching increases memory usage and decreases the benefits of stack segments! 4. The benefit above is significantly reduced when calling into C code, and all solutions to this either hurt the benefit more or significantly penalize the FFI. I think that segmented stacks just don't work. *Relocatable* stacks may work, but not in Rust. From what I have read, Walter Bright and Rob Pike agree. At this point I'd like to suggest just allowing the user to choose a stack size on a per-task basis, and failing if the stack size is exceeded. Basically `__morestack` would turn into `fail`. Brian has pointed out to me that, currently, running out of stack has to abort the whole process, because the DWARF unwinder doesn't consider `__morestack` a may-throw position and as a result the arguments would leak. There are a number of ways we could fix this, ranging from principled to hacky. But for now I think aborting on stack exhaustion wouldn't be the end of the world (although others may disagree). Patrick __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Remove `float` from the language
History lesson, The correct term to use is really floating point register. But the idea of a float that is being tossed in this discussion is really a float variable. This is what Graydon is talking about I pretty sure: http://www.gnu.org/software/gsl/manual/html_node/Examining-floating-point-registers.html There is a difference in terminology depending on WHAT you are really talking about, but it appears that Graydon rocks it old school, as we all should when discussing the register capabilities themselves of the hardware (in years past an FPU... in current architectures a SIMD capable processor.) Besides all these terms are in the IEEE standards anyways http://en.wikipedia.org/wiki/IEEE_floating-point_standard (class dismissed) ;-) On Tue, Jul 2, 2013 at 1:07 AM, Daniel Micay danielmi...@gmail.com wrote: On Tue, Jul 2, 2013 at 1:09 AM, Robert O'Callahan rob...@ocallahan.org wrote: Seems to me you could quantify the performance impact of variable-width types. E.g. try making 'int' 32-bit on a 64-bit architecture and see how much it hurts. I'm suspicious they're a premature optimization. Rob The int and uint types match the pointer size, and if they aren't the same size the existing standard library (including things like vectors) won't work. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] tree maintenance
Thanks again for everyone's patience. I remain convinced that having automatic integration is worth much more than a free-for-all on the tree, That alone is worth more than 20 new active developers, I would say. Thanks for your hard work on this Graydon, and team ! -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust on microcontrollers and embedded systems
I would rather see Atmel AVR or ARM Cortex M0 as targets. Also, would low voltage, low power 8-bit targets with under 512KB ram be impossible ? On Fri, Jun 21, 2013 at 10:20 AM, Thomas Daede daede...@umn.edu wrote: Hello, I'm relatively new to Rust, and this is the first time I've posted on this list. For my senior honors thesis, I would like to improve Rust so that it can be used on microcontrollers and other small embedded systems. This is a sector dominated by C and has seen little change for quite a while, due to most other languages not meeting the unique requirements. Besides being constrained in RAM and CPU power, the program binary also generally runs directly out of NOR Flash based ROM, so that the binary code itself takes no RAM space. This precludes most JIT based systems - interpreter based languages take less RAM, but are also very slow. Rust is in many ways a very good fit for microcontrollers. Its memory safety is very useful for many different applications, and helps greatly for task isolation on systems without memory protection. In addition, memory allocation is explicit so the programmer can choose where best to allocate the RAM - important for things like avoiding the GC in sensitive code regions. And of course, there are all the other benefits that Rust has compared to C in general. However, Rust isn't ready for microcontrollers yet. Here's what I plan to implement, in order: - Static linking for runtime and Core crate - Compiling runtime and Core without thread support - Adding compatibility with the newlib C library - Adding configurable stack allocation - Adding arm-none-eabi target - Wrappers around a native C peripheral library, such as libopencm3 This should be the bare minimum to get a demo up and running. I plan to target the STM32F4 series of microcontrollers initially, using libopencm3's linker scripts, and the C compiler and linker from gnu-arm-embedded. I know there has been some work to remove the dependency on the core and runtime libraries, however it seems difficult to strip them out entirely, and I think they are useful enough that I would rather port them instead. I would like to know if anyone else has tried this yet, or has comments about how this should be implemented. - Thomas Daede ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust on microcontrollers and embedded systems
I was thinking more of Industrial systems VS. Gadgetry Robotics projects. No problems. Getting support for the M0 will be important long term is what I am saying. On Fri, Jun 21, 2013 at 10:53 AM, Thomas Daede daede...@umn.edu wrote: On Fri, Jun 21, 2013 at 10:33 AM, Thad Guidry thadgui...@gmail.com wrote: I would rather see Atmel AVR or ARM Cortex M0 as targets. Also, would low voltage, low power 8-bit targets with under 512KB ram be impossible ? Where are you finding 8-bit targets with 512KB ram? Generally they have 8K or less. The highest end device I plan to work on only has 192KB of RAM. ARM Cortex-M0 is very similar to Cortex-M4 - it's a subset of ARMv6 rather than ARMv7 technically, so it needs different compiler options to LLVM, but I would like to support it too. It's easier to develop on the M4 though, just because of the RAM - ST sells a devkit for $15 that includes a processor with 1MB of Flash and 192KB of SRAM. Once I get it working there, I'll probably add support for the M3 and M0/M0+ too. AVR doesn't have a LLVM backend, nor do I think one would be worthwhile, when vendors like NXP are selling Cortex-M0 chips for under $1.00. The ARM NVIC is also a lot nicer and it should be relatively easy to implement interrupt routines in pure Rust (with a C method signature) -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] tree maintenance
On Tue, Jun 18, 2013 at 10:28 AM, Graydon Hoare gray...@mozilla.com wrote: On 13-06-17 06:21 PM, Thad Guidry wrote: Nice. Will there also be a Snapshot for 64 bit Windows ? Unfortunately nobody has spent the requisite time to enable the mingw-w64 port yet. I saw some rumblings of it but there's no support in-tree for it yet. Similarly, no support for clang-only win32/64 nor msvc32/64. Right, OK, I remember that I should be trying to spend some time with getting a mingw-w64 port. (My Cygwin adventures had detoured towards that) So, I probably need to go back and work my way up that food chain (tool chain) again but with my (now working properly and documented on the wiki now...) MinGW installation. When there's support for any of these variants, yes, absolutely. OK, so if I pull off a nice port to enable mingw-w64 then you (we) will support it as a Snapshot. Gotcha. Thanks, -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] tree maintenance
Nice. Will there also be a Snapshot for 64 bit Windows ? On Mon, Jun 17, 2013 at 7:57 PM, Graydon Hoare gray...@mozilla.com wrote: Hi, As part of preparation for 0.7 (due around the end of june / early july) we're going to be closing the tree for a while, fixing the lingering breakage that's snuck through 'auto' and accumulated on 'master', and greatly widening the 'auto' coverage such that this stuff doesn't build up anymore. For now, bors is turned off and the tree is closed. Fear not though: this should ultimately improve life for everyone. More coverage, better differential testing, less chasing ghosts. Thanks for your patience. It'll be back asap (along with a snapshot!) -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] code generation and rustc speed
From a holistic approach, does this problem point to : 1. More LLVM tweaking in general is needed ? 2. More use of libraries and better libraries are needed ? 3. Both 1 and 2 ? On Sat, Jun 15, 2013 at 3:26 AM, Graydon Hoare gray...@mozilla.com wrote: I saw some more speculation on how to make rustc not-so-terriby-slow to compile today, including dramatic structural changes like splitting it into sub-crates. Please don't do this; it's papering over much more readily solvable problems. A 80kloc library does not need to be generating 16mb of object code. Here are two simple listings of symbols we're generating: http://people.mozilla.org/~**graydon/symbols-by-size.txthttp://people.mozilla.org/~graydon/symbols-by-size.txt http://people.mozilla.org/~**graydon/symbols-by-name.txthttp://people.mozilla.org/~graydon/symbols-by-name.txt Some things should be immediately apparent: - We're generating some (not all) _very_ large functions. Look at ty::mk_ctxt. It's a single constructor call. It produces 133kb of code. This has got to be some quadratic codegen bug. - There are 15762 functions but only 2039 unique function-sizes. We're not collapsing a _lot_ of identical functions. - We're generating a _lot_ of monomorphic instances. There are 363 hashtable:: functions in there -- about 50 copies of the std::hashtable module. Similar number of copies of std::vec. 68 copies of extfmt::conv_poly. 392 visit:: functions. - We're still generating a _lot_ of glue. Very little of it seems to be properly recycled -- there are many copies of each glue for types that vary only in a not-used type param, of identical size. 7134 of the 15762 functions are glue. Beyond all that, there are pretty apparent systemic taxes as soon as you start digging into the LLVM. Take a look at, say, http://people.mozilla.org/~**graydon/graph.svghttp://people.mozilla.org/~graydon/graph.svg-- the CFG from middle::trans::inline::maybe_ **instantiate_inline for example. It's a very modest 100-line function with 3 or 4 of nested matches. It produces 687 CFG nodes, 903 edges, and 8068 LLVM instructions (and that's a _small_ one -- it only winds up as 7k of object code). There are a lot of things in there that shouldn't be being-generated. -Graydon __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Scheduler and I/O work items for the summer
I know that Rust currently doesn't currently support this, but what if futures could use a custom allocator? Then it could work like this: 1. Futures use a custom free-list allocator for performance. 2. The I/O request allocates new future object, registers uv event, then returns unique pointer to the future to its' caller. However I/O manager retains internal reference to the future, so that it can be resolved once I/O completes. 3. The future object also has a flag indicating that there's an outstanding I/O, so if caller drops the reference to it, it won't be returned to the free list until I/O completes. 4. When I/O is complete, the future get resolved and all attached continuations are run. Vadim Brian, Vadim described the idea fairly well there with the meat of my idea being # 2. I was just trying to describe the scenario that # 4 be able to happen only when all the registered event(s) happen (not just 1 blocking step but perhaps many blocking steps). I would not know where to start mocking something like that with Rust yet... still beginning. -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Scheduler and I/O work items for the summer
## Design and implement some solution for select / async events We need a way to efficiently wait on multiple types of events at once, including port receives, I/O reads, socket accepts, timers. This has some very complicated requirements to satisfy, as detailed in the linked issue, and I'm not sure what the right abstractions are here. This is super important and the biggest risk to the whole effort. If anybody has opinions about this topic I would love to hear them. https://github.com/mozilla/**rust/issues/6842https://github.com/mozilla/rust/issues/6842 My 2 cents worth nothing :-) and I've replied inside the issue with the same idea... It seems to be very similar in tone to what Vadim described for .NET asyncs where you wait for a timeout or all operations (steps) to complete from an abstract view. This idea comes out of the Data Architect world that I live in. It's more along the lines of that basic idea that your pitching which I call receivership. In Pentaho Data Integration, there is a process step called Block this step until steps finish. What it does is Block a single step in an execution flow until a selected step or even multiple steps somewhere in the chain or process has completed it's execution and returned a True for it's execution complete flag where a launched listener is waiting and watching. It's a generic wrapper if you will, for additional next steps to perform, but those next steps do not get called, do not get any input, and no variables are passed to them until the child Blocking step has seen from (there's a listener process launched for each step or steps choosen to watch) all its parent or parents steps somewhere say that it's own execution has finished and lets the listener know. I think the Block this step until steps finish just waits for all those listeners it is watching to say it's OK to proceed with it's own set of next steps. -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Summer of Code 2013: Rust Debug Symbol Generation
Best of luck Michael and thanks for tackling this objective ! The only quick advice I have is too let you know that Eclipse can be a nice frontend for GDB itself, in case your not aware... http://dpc.ucore.info/blog/2013/02/06/eclipse-as-an-excellent-gdb-frontend/ On Wed, May 29, 2013 at 10:01 AM, Michael Wörister michaelwoeris...@gmail.com wrote: Hi everyone, I wanted to quickly introduce myself here. My name is Michael Woerister and I was accepted for Rust's Google Summer of Code project this year, regarding debug symbol generation for rustc. I've been following the Rust project for a while now and I'm really proud that I can be a part of it. Rust already is a beautiful language and I hope to be able to use it a lot in the future. It's great to get this opportunity of contributing some to its progress! A bit about the project: Debugger support for Rust is very rudimentary at the moment. LLVM allows for producing debug symbols during code generation but for this to work the LLVM IR has to be annotated correctly with metadata. Some of this is already implemented in librustc/middle/trans/debuginfo.rs but quite a few things are still missing. At the same time the language is still evolving and like other parts of the compiler the debug symbol code has to keep up. Also new LLVM versions come with their needs for adaption. My task over the summer will be to extend the code in debuginfo.rs to also handle things like enums, traits, and closures, and just as important, write more unit tests so the 5 lonely files in test/debug-info get some company. The goal is that at the end of summer we will be able to debug rustc itself with gdb. I will post my weekly project updates to my github page: http://michaelwoerister.github.io (nothing there yet) I am grateful for any advice or comments. Also, I want to thank my 'GSoC mentor' Josh Matthews who has been nothing but helpful so far :-) Cheers, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] A case for removing rusti
RUST RUN. FTW. :-) On Wed, May 29, 2013 at 4:29 PM, John Clements cleme...@brinckerhoff.orgwrote: On May 29, 2013, at 10:32 AM, Graydon Hoare wrote: ... I agree that a 'rust run' command, or indeed exploiting our support for shebang comments[1], should be sufficient for most users. But I'm not convinced the repl serves no purpose, yet (though it's true, I don't use seem to ever use it; I also write surprisingly little rust code these days). People ask for it, and it doesn't really bend the language any to support it. It _is_ a code-maintenance cost, of course, so I'm also curious what others think in terms of the balance of costs/benefits. My vote: dump it. This might sound surprising from a Schemer, but probably not from a Racketeer. Making the top-level work correctly soaked up far too much time in the Racket environment. There's nothing more infuriating than getting something to work in the REPL and then discovering that it doesn't work in compiled code… unless it's struggling for weeks to get something to work in the REPL, only to discover that it works just fine in compiled code. I think that the principal use case for a REPL is interactive exploration of what rust programs mean, and I think that the best way to support this is to have a nice clean rust run, and possibly some sugar that makes evaluating and printing the result of a single expression more convenient. My opinion only. John ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] MinGW and Rust for Windows Users
I asked the libuv folks on their IRC channel and this was Mr. Fontaine's response: tjfontaine irc://freenode/tjfontaine,isnickfor some reason that compile line doesn't have the include directory, you should really take that up with the rust folk. On Sun, May 5, 2013 at 12:13 AM, Thad Guidry thadgui...@gmail.com wrote: So, I went back to MinGW and managed to get a compiler chain for Windows 7 64bit working with mingw64 and using MingGW / Msys and additionally I was able to get the Wget gui to actually work correctly... so in essence, Windows users will have a nice gui like interface to install the Unix tools they need for the compiler chain. In the Msys terminal window, you just type mingw-get and it launches the gui. The only thing that is not packaged up in the gui as a mouse click away is the actual headers and CRT for Mingw64 for gcc to use. The headers/CRT is currently a separate download and has to be unzipped into the C:\MinGW folder. LLVM seemed to get built just fine under Release+Asserts it says. Libuv is a different matter... it can't find uv.h for whatever dasterdly reason, even though it is sitting right there under its foot C:/MinGW/msys/1.0/home/Thad/rust/src/libuv/include/uv-private (folder) C:/MinGW/msys/1.0/home/Thad/rust/src/libuv/include/uv.h (file) Here's the paste and asking the community for help on what next ? .. http://pastebin.mozilla.org/2375997 -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] MinGW and Rust for Windows Users
Worked with Mr. Fontaine on ensuring that it was a Rust issue and not Libuv issue ... we built and tested Libuv under my Mingw sys and tested just fine with this output and verified by him as OK. http://pastebin.mozilla.org/2377431 On Sun, May 5, 2013 at 1:55 PM, Thad Guidry thadgui...@gmail.com wrote: I asked the libuv folks on their IRC channel and this was Mr. Fontaine's response: tjfontaine for some reason that compile line doesn't have the include directory, you should really take that up with the rust folk. On Sun, May 5, 2013 at 12:13 AM, Thad Guidry thadgui...@gmail.com wrote: So, I went back to MinGW and managed to get a compiler chain for Windows 7 64bit working with mingw64 and using MingGW / Msys and additionally I was able to get the Wget gui to actually work correctly... so in essence, Windows users will have a nice gui like interface to install the Unix tools they need for the compiler chain. In the Msys terminal window, you just type mingw-get and it launches the gui. The only thing that is not packaged up in the gui as a mouse click away is the actual headers and CRT for Mingw64 for gcc to use. The headers/CRT is currently a separate download and has to be unzipped into the C:\MinGW folder. LLVM seemed to get built just fine under Release+Asserts it says. Libuv is a different matter... it can't find uv.h for whatever dasterdly reason, even though it is sitting right there under its foot C:/MinGW/msys/1.0/home/Thad/rust/src/libuv/include/uv-private (folder) C:/MinGW/msys/1.0/home/Thad/rust/src/libuv/include/uv.h (file) Here's the paste and asking the community for help on what next ? .. http://pastebin.mozilla.org/2375997 -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] lib: regular expressions in std
Devin, I personally would like to see a Rust regex engine. It could also serve as a new reference standard going forward with the language design where additional tests could be bound to it. A win - win in my opinion for proving the language design in the first place. Java, Python, and Ruby, to name a few...share very similar syntax styles or flavors. You can scroll down this page to see the subtle differences between all the flavors, including those 3. http://www.regular-expressions.info/refflavors.html I am sure you have intentions to develop the Rust regex engine to have a very similar flavor, so I am not worried personally. Just cover the basics with that aligned Rust regex flavor and most folks will be quite happy, everything else can be easily looked up in a reference, as is usually the case for most developers, unless you live and breath regex everyday. Unicode Level 1 and with most of Level 2 would be a requirement in my opinion. It is the world we live in today, thankfully, at last. :) On Sat, May 4, 2013 at 8:54 AM, Devin Jeanpierre jeanpierr...@gmail.comwrote: With regards to https://github.com/mozilla/rust/issues/3591 , I'd like to write a regular expression module for Rust. I've written a couple of regular expression engines in Python for fun in the past[*], and #rust pressured me to utilize my perverse sense of fun to write the same for Rust. Actually, the reason I learned Rust was to port a bunch of my regex code to a nice language. :) I'm writing this email because https://github.com/mozilla/rust/wiki/Library-editing told me to. I don't know much about the process, but as I understand it this marks the beginning of a one week discussion period where Rust-Dev fleshes out ideas for such a module, and whether or not it deserves to be written, and whether or not I should be the one writing it. I've also added this library page to the wiki: https://github.com/mozilla/rust/wiki/Lib-re I've already discussed this somewhat with some people in #rust, especially Marvin Löbel (kimundi) has been interested in helping me come up with a nice API. Hopefully we can put that down in writing here so that it isn't just in our memory. Some questions to start off with: - Should rust have a new regex engine written in Rust, or should it just have bindings for e.g. RE2 or similar? A point brought up in #rust: if we use RE2 or similar, we may not be able to have a re!() syntax extension that compiles regexps at the same time as the surrounding rust code. I prefer the former, because I wanted to write a new regex engine regardless. I would be perfectly happy to write some nice bindings for something like RE2, but I am probably not the best person to do it. - What syntax/semantics are important? I would propose supporting the usual PCRE syntax and semantics (including submatch extraction), but with the exception of backreferences and any other features which cannot be implemented efficiently (i.e. polynomial time). RE2 has a good summary of regex syntax, although it doesn't specify for PCRE-family syntax whether it comes from perl, libpcre, python, or something else. http://code.google.com/p/re2/wiki/Syntax Note: if rust's re module is efficient, syntaxes for things like possessive quantifiers is pointless and can be dropped. It may be desirable to include alternate parse disambiguation strategies. Using efficient RE, it's fairly easy to support POSIX-style longest match, as well as PCRE-style matches and even shortest match. For example, RE2 offers support for PCRE-style and also POSIX style regex matching. - How important is Unicode support and how broad should that support be? My understanding is that, at least as long as it can be added later, this is not crucial to get right correct right away. Unicode TR-18 defines 3 levels of Unicode support in regex implementations, of which only the first two are relevant. I think the only thing missing from core::unicode to give level 1 support is simple case folding. * https://github.com/mozilla/rust/issues/5820 * http://www.unicode.org/reports/tr18/ That's probably enough to start off with, especially since the answer to question 1 ties our hands on everything afterwards. Also since my hands hurt from typing. However, there's a lot of other topics, like what the API should look like, whether or not to support various syntaxes, etc.. I've added a lot of links and a few additional topics to the library proposal page. link again: https://github.com/mozilla/rust/wiki/Lib-re Let me know if there's something I've left out of here or of the library proposal page. When there's more discussion / I have more energy, I will suggest some of my personal ideas of what I'd like in a regex module, but somehow I don't feel that's appropriate at the top level post.
[rust-dev] MinGW and Rust for Windows Users
So, I went back to MinGW and managed to get a compiler chain for Windows 7 64bit working with mingw64 and using MingGW / Msys and additionally I was able to get the Wget gui to actually work correctly... so in essence, Windows users will have a nice gui like interface to install the Unix tools they need for the compiler chain. In the Msys terminal window, you just type mingw-get and it launches the gui. The only thing that is not packaged up in the gui as a mouse click away is the actual headers and CRT for Mingw64 for gcc to use. The headers/CRT is currently a separate download and has to be unzipped into the C:\MinGW folder. LLVM seemed to get built just fine under Release+Asserts it says. Libuv is a different matter... it can't find uv.h for whatever dasterdly reason, even though it is sitting right there under its foot C:/MinGW/msys/1.0/home/Thad/rust/src/libuv/include/uv-private (folder) C:/MinGW/msys/1.0/home/Thad/rust/src/libuv/include/uv.h (file) Here's the paste and asking the community for help on what next ? .. http://pastebin.mozilla.org/2375997 -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] What parts of libuv are used ? why ?
Looks like libuv is a showstopper currently for me on Windows Cygwin building. Why is it used ? Should it be ? Will it be in the future ? Can someone throw up a quick paragraph or 2 about this on the wiki and let me know ? Thanks in advance ! -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
Thanks to the incredible outpouring of support from the community on IRC to help me get Cygwin supported, tonight I had somewhat better success... as I have been patching my way through Rust's source with the help from those incredible IRC folks. Thanks guys and gals ! We have been adding if define's etc... for __CYGWIN__ such as... #if defined(__WIN32__)|| defined(__CYGWIN__) etc... and also patched rust_task.h to support Cygwin RED_ZONE_SIZE, all of which might need further tweaks... but anyways... We have hit a snag that we are not sure what to do about... error during make with GCC 4.5.3 (not Clang, since there will be other issues to address there later) on Cygwin ... http://pastebin.mozilla.org/2367675 Thoughts ? -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
This FAQ has most of those answers, Corey, just scroll down it to see the API and Programming Questions : http://cygwin.com/faq/ On Wed, May 1, 2013 at 10:47 PM, Corey Richardson co...@octayn.net wrote: On Wed, May 1, 2013 at 11:34 PM, Thad Guidry thadgui...@gmail.com wrote: Thanks to the incredible outpouring of support from the community on IRC to help me get Cygwin supported, tonight I had somewhat better success... as I have been patching my way through Rust's source with the help from those incredible IRC folks. Thanks guys and gals ! We have been adding if define's etc... for __CYGWIN__ such as... #if defined(__WIN32__)|| defined(__CYGWIN__) etc... and also patched rust_task.h to support Cygwin RED_ZONE_SIZE, all of which might need further tweaks... but anyways... We have hit a snag that we are not sure what to do about... error during make with GCC 4.5.3 (not Clang, since there will be other issues to address there later) on Cygwin ... http://pastebin.mozilla.org/2367675 Thoughts ? -- -Thad http://www.freebase.com/view/en/thad_guidry It seems libuv has no support for cygwin as a platform. Is it possible to compile native win32 apps using cygwin, as one would with mingw? I am unfamiliar with cygwin and windows in general. -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
I have mingw64 installed. See my Cygwin Setup screenshot here: https://docs.google.com/file/d/0B533WzlrxWraSHgzdVpGM29WQ1k/edit?usp=sharing On Wed, May 1, 2013 at 10:56 PM, Corey Richardson co...@octayn.net wrote: On Wed, May 1, 2013 at 11:49 PM, Thad Guidry thadgui...@gmail.com wrote: This FAQ has most of those answers, Corey, just scroll down it to see the API and Programming Questions : http://cygwin.com/faq/ So from http://cygwin.com/faq/faq-nochunks.html#faq.programming.win32-no-cygwin, perhaps you should try using mingw-gcc, and see how far that gets you. -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
Sorry... in the screenshot Current column shows what I have installed currently. On Wed, May 1, 2013 at 11:03 PM, Thad Guidry thadgui...@gmail.com wrote: I have mingw64 installed. See my Cygwin Setup screenshot here: https://docs.google.com/file/d/0B533WzlrxWraSHgzdVpGM29WQ1k/edit?usp=sharing On Wed, May 1, 2013 at 10:56 PM, Corey Richardson co...@octayn.netwrote: On Wed, May 1, 2013 at 11:49 PM, Thad Guidry thadgui...@gmail.com wrote: This FAQ has most of those answers, Corey, just scroll down it to see the API and Programming Questions : http://cygwin.com/faq/ So from http://cygwin.com/faq/faq-nochunks.html#faq.programming.win32-no-cygwin, perhaps you should try using mingw-gcc, and see how far that gets you. -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
Really? Then that actually makes things a bit easier. So, I customize the Rust build and write steps for users to compile LLVM, Clang, and Rust using Cygwin on their Windows machine. OK. On Apr 29, 2013 3:10 AM, Sanghyeon Seo sh4@samsung.com wrote: I am still investigating why Clang 3.1 / LLVM from the Cygwin package are not correctly setup or working well with the Rust setup and configuration, Rust won't compile with LLVM 3.1. This is expected. https://mail.mozilla.org/pipermail/rust-dev/2013-April/003518.html ___ 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] No range integer type? Saftey beyond memory?
Rust user base on a used napkin: 80% want safety. 100% want speed. 10% want it all. 50% do not care. Rust will be aiming to please those 80% ...that also happen to like tacos and bacon and wont complain because they will be happy, full, productive, and content. Order your t-shirts now. :) -Thad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
Gist link shows where I tried to build Rust with Cygwin and Clang-LLVM 3.3 (trunk) tonight... but didn't seem to go all that well, however... ideas ??? https://gist.github.com/thadguidry/5486263 -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
Apparently, you really DO NOT want to install Collabnet Subversion client on your Windows system, or Tortoise SVN , because both of these default to checking out with Windows style End Of Line: CRLF. Instead of UNIX style: LF which is the default for Cygwin's installation. My Subversion client from Collabnet was getting loaded first in my $PATH and taking precedence instead of the Cygwin Subversion client. ARGHH ! The easy fix for this was... uninstall Collabnet's version (since I really had no direct use for it, and used it on the command line anyway, which is the same thing I can do with Cygwin's Subversion.) I then also removed the Collabnet path from my Windows environment variable path and then all was well with checking out LLVM and Clang trunk manually. I am still investigating why Clang 3.1 / LLVM from the Cygwin package are not correctly setup or working well with the Rust setup and configuration, but until then, I'm going to try a build of Rust with a built Clang / LLVM in my Cygwin environment to see if there is any difference. I then might have to get with the Cygwin guys to find out where the mixup might be happening. Stay Tuned... -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] stmt inside expr grammar question
John,
Functional ways would be an approach I would admire and +1 for.
I like the alternative also. In OpenRefine with the GREL expression
language, we did something similar.
Parenthesis rule. Go Lisp. err, wait, Go Go. Oops, wrong business... Go
Rust !
On Thu, Apr 25, 2013 at 1:46 PM, John Clements cleme...@brinckerhoff.orgwrote:
Huh? Looks like my first message didn't go through. Perhaps I'm being
moderated, and I just didn't know it?
Apologies if this appears twice.
Per our meeting today, I'm sending this out to see whether we want to make
a change.
Currently, our grammar parses
if (true) {3} else {4} + 10
As a statement followed by a (non-parseable) expression. This is to
prevent things like
if (true) {3} else {4}
|a| {foo()}
… from being parsed as two uses of the or operator, for instance. The
basic restriction is that when something that could be a statement occurs
in a position where it could be a statement, then it should be parsed as a
statement and not as an expression.
Keep in mind that you can always force a statement-y thing to be allowable
in any position by using parens. So, for instance,
(if (true) {3} else {4}) + 10
is a perfectly legitimate expression.
This restriction is the cause of no small ugliness in the grammar.
Simplifying it might concievably avoid certain errors. However, it would
probably make some people unhappy.
One way to fix it would be simply to lift the restriction entirely. In
this case,
if (true) {3} else {4}
|a| {foo()}
… would be parsed as
((if (true) {3} else {4}
|a)
| {foo()})
… which some people might be surprised by.
Another solution would be to *always* require semicolons, even after
blocks. This would probably make lots of people immediately unhappy.
Another solution, the shift the burden to those kooky functional folks,
would be to say that using a statement as an expression *only* works when
it's enclosed in parens. This would simplify things a lot. This would not
change the behavior of the first example at all, but it would for instance
rule out
14 + if (true) {3} else {4}
… requiring instead
14 + (if (true) {3} else {4})
But indeed, I think I would probably opt for the latter one as more
readable anyway.
Another example that would have to change would be changing something like
for foo.each |a| {f(a)}.bar()
into
(for foo.each |a| {f(a)}).bar()
But honestly, that one makes me happier as well.
The more I think about this alternative, the more I like it.
Either way, this ship's gangplank is up and it's straining at its hawsers.
We should probably make a decision on this now-ish.
John
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
-Thad
http://www.freebase.com/view/en/thad_guidry
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Renaming of core and std
+1 Prime Prime comes from the Latin prīmus , which means First... so it's above Chosen, Favored, Normal, Selected, and all the rest. In Old French, prim, means the first hour, go fig. On Wed, Apr 24, 2013 at 5:58 PM, Graydon Hoare gray...@mozilla.com wrote: On 13-04-24 01:05 PM, Benjamin Striegel wrote: It's important to keep in mind that much of the value of calling something the standard library is so that users *know* that the libraries within are blessed by the language developers themselves, and therefore gives them the peace of mind that the code within is featureful, reliable, supported in the long-term, and well-known by the community. Please select a name that adequately expresses the authority of such a library. Agreed. This packaging will be of a sort that _does_ represent a level of support from the language maintainers, version-to-version. So ... absent other suggestions I will return to my preferred passtime of thesaurus hunting: - Common - Platform - Staple - Stock - Supported - Base - Basis - Usual - Normal - Favored - Selected - Endorsed - Chosen - Prime Any of these sound pleasant to the hear? -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM Clang and Cygwin happiness (not quite yet)
OOps, let's try that again with including the pastebin URL ! http://pastebin.mozilla.org/2344954 On Wed, Apr 24, 2013 at 11:25 PM, Thad Guidry thadgui...@gmail.com wrote: I've been working on getting the right settings, configure options, etc... for Windows users to setup a Cygwin installation and be able to use it to build Rust with Clang / LLVM. We've run into a few problems and I'm asking the community for a bit of help. It seems that there's a Clang test that fails, and apparently because the header files are not correctly found for whatever reason. Here's the pastebin of the current Cygwin environment I'm working against and modifying as I go along...that shows the errors and my directory structures under a Cygwin install...hope it reads well enough for folks to understand. I need help with trying to understand why Clang or my setup in Cygwin might be confused with this test_me.c that Brian found for me: https://gist.github.com/brson/5456999 -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Renaming of core and std
+1 for extra. It has a nice semantic smiley face all over it. On Tue, Apr 23, 2013 at 11:35 AM, Patrick Walton pwal...@mozilla.comwrote: Hi everyone, There's been consensus lately that `core` and `std` are somewhat misnamed. `core` is really the standard library--the one that would be specified in a specification if we had one. `std` is an extras library and may well end up sliced up and moved to various packages. So it seems prudent to rename `core` to `std`. But that leaves the question of what to name `std` in the interim. Options that have been suggested are `extra`, `ext`, and `contrib`. Any other opinions? Patrick __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] New milestones, bug triage, maturity and completion
So what are the 2 labels applied for the milestones ? Was that 1. PREDICTIVE MILESTONES 2. MATURITY MILESTONES ?? On Mon, Apr 22, 2013 at 10:44 PM, Graydon Hoare gray...@mozilla.com wrote: Hi, Mozilla research had a workweek recently where we discussed a number of process changes to the Rust project to try to bring a little more order to the chaos and wind down the rapid-growth, everything-on-fire phase of the project. This email explains those process changes in a little more detail. If you're employed on this project full time, please read this email carefully. 0. Bors, incoming and master Bors has been generally judged a success (modulo annoyingly regular timeouts on the buildbot) so we will be deleting the incoming branch and switching bors to move master directly. I'll send another notice when this is ready to happen. 1. Milestones split into two groups Previous rust releases have used milestones ineffectively, as they blurred the distinction between aspirations (we think this bug _should_ get done) and prediction (we think this bug _will_ get done). As a result, they served neither purpose and were frequently overlooked or ignored. We will attempt to breathe new life into the milestone facility by splitting their roles into separate sets: for 0.7 and onwards, release-numbered milestones (0.7, 0.8, 0.9, etc.) will be _predictive only_. Bugs should be placed on those milestones only if they are assigned to you, and represent your best guess about _what you will do_ during a release cycle. You can take something off that milestone if it's assigned to you and you don't think you'll get it done, whenever you see fit. These milestones will have associated target dates, which we will aim to maintain on the quarterly cadence we've maintained so far. A separate set of milestones has been added called maturity milestones. These have no dates, and are aspirational: they define subjective concepts backwards compatible or feature complete in terms of specific bugs, for external measurement of the project's state. The project's maturity can be judged against these more usefully than it can be judged against milestones like 0.7 (which tells the reader very little). Bugs will be assigned to maturity milestones by a nomination process. That's point #2. Maturity milestones will be reached when we get there; we will not hold releases for them. What we call 1.0 is a different conversation, but I imagine it needs to be somewhere after the backwards compatible milestone, just to suit the concept of major-version numbers in semantic versioning. 2. Nomination and acceptance Maturity milestones represent a subjective judgment about product maturity, as seen through the eyes of the repository owners (that is, mozilla engineers). Of course you're welcome to consider maturity in different terms, but this is for our own planning and measurement of the project. As such we'll be accepting _nomination_ of a bug for inclusion in one of these milestones liberally -- anyone should feel free to nominate a bug if they think it's really important -- but meeting weekly to either _accept_ or _decline_ inclusion in these milestones. This way we hope to establish and communicate a consensus concerning the project status and path towards completion. There is a new tag I-nominated for tagging a bug with nomination. These will be cleared weekly, at the meeting. Bugs that we decline to add to a maturity milestone will remain in the general bug pool, and will be addressed best effort by the repository owners, or (of course) through contributed pull requests. It's still worth keeping non-milestone bugs around. I should reiterate: the maturity milestones are there to _sharpen a concept_ like feature complete or backwards compatible into a particular bug-set. They are not there for scheduling a bug you want to get done because it seems cool. The idea is that a bug should be assigned to a maturity milestone where it would be a _untenable_ to claim or argue the terms of the milestone were met without that bug. As such, the maturity milestones have extensive text associated with them. Please read them to make sure you understand the idea behind each: https://github.com/mozilla/**rust/issues/milestoneshttps://github.com/mozilla/rust/issues/milestones 3. Randomized triage and fixing in the general bug pool I've added a new script to our repertoire of project automation that selects a set least-recently-edited bugs every week and randomly assigns them in batches for triage to a set of project participants (who have signed up for this fate -- email me if you want to join in). This way we hope to visit, self-nominate, review and close bugs at a better rate and a more uniform breadth than we've been doing so far; and to improve this rate as we advance towards feature completion and can focus more and more energy on bug fixing. If you received a set of bugs
Re: [rust-dev] LLVM versions
I would not spend a lot of energy supporting multiple versions. As many versions as are easy is fine by me. LLVM is big but not impossibly big, and if we wind up needing a different-than-trunk version on a given system, I think it will not be the end of the world. -Graydon +1 not the end of the world. -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] getting rid of let a=3, b=4? (bikeshed alert)
What's the problem that develops with that form for you John ? -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] wanted libraries
Approximate String Matching routines would be nice, if not already available... Perhaps performing similar functions such as Second String http://secondstring.sourceforge.net/ On Tue, Apr 9, 2013 at 12:54 PM, John Mija jon...@proinbox.com wrote: +1 for internationalization/**localization; it's complex and the solution should be designed by the Rust team. +1 for tokenizer, parser, just like Go has: http://golang.org/pkg/go/ This will allow to build tools like gofmt (to format Rust code) -1 for protobuf and thrift since they are not standard. Instead, I prefer csv in the standard library * The library math should be in the library since it's something basic to create things related to image and audio. In addition a language like JavaScript comes with that library included: https://developer.mozilla.org/**en-US/docs/JavaScript/** Reference/Global_Objects/Mathhttps://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Math El 08/04/13 16:42, Olivier Renaud escribió: Hi, I saw the [wanted libraries] page on the github wiki, and I'd like to submit some ideas there. The wiki page is read-only, so I fall back on submitting them on this list. I tried to confine myself to what would be useful to me, in a stdlib. * Internationalization : mechanisms for handling the internationalization of UI texts - one aspect of i18n is to map a key to a text, based on the current locale (eg Java's [ResourceBundle]) - another aspect is to format a string based on the current locale (eg Java's [MessageFormat]) * Libicu is already listed on the wiki, but there are no details of what is needed. Here are my suggestions : - Convertions between text encodings. Ideally, with a customizable way of handling conversion errors. - Unicode normalization (NFD, NFC, NFKD, NFKC) - Collator (locale sensitive string comparison), with a configurable degree of strictness * Simple (yet powerful) search on a filesystem (eg Ruby's [glob]) * A simple tokenizer/file parser * Support to read/write zip and tar file formats (not only the gzip algorithm) Olivier Renaud ___ [wanted libraries] https://github.com/mozilla/**rust/wiki/Note-wanted-** libraries https://github.com/mozilla/rust/wiki/Note-wanted-libraries [ResourceBundle] http://docs.oracle.com/javase/**7/docs/api/java/util/** ResourceBundle.htmlhttp://docs.oracle.com/javase/7/docs/api/java/util/ResourceBundle.html [MessageFormat] http://docs.oracle.com/javase/**7/docs/api/java/text/** MessageFormat.htmlhttp://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html [glob] http://ruby-doc.org/core-2.0/**Dir.html#method-c-globhttp://ruby-doc.org/core-2.0/Dir.html#method-c-glob __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] FastCGI implementation
Perhaps the Cherokee webserver might be useful for you to look at it's codebase... and it's implementation of fastcgi.h https://github.com/cherokee/webserver/tree/master/cherokee On Fri, Apr 5, 2013 at 9:13 PM, Andres Osinski andres.osin...@gmail.comwrote: Hi everyone, I've taken an interest in Rust as it fills a niche in programming that I've long been looking to fullfill. I'm primarily a Python web developer, so I wanted to start coding by implementing the FastCGI protocol for Rust. I know that its native task management and socket capabilities are very good, but you never know when it might be handy for someone. I just wanted to know if anyone was familiar with the FCGI protocol, and if there's any reference as to how to manage the packing and unpacking of C data structures, as well as if you know of any implementation for a similar protocol. One small question that I have is that FCGI protocol defines a struct with two char arrays whose length is defined by another field within the struct, and I was wondering how that would be modeled in Rust. Thanks -- Andrés Osinski ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] FastCGI implementation
oops, that should have been the handler portion of Cherokee FastCGI ... https://github.com/cherokee/webserver/blob/master/cherokee/handler_fcgi.c more docs here: http://www.cherokee-project.com/doc/modules_handlers_fcgi.html On Sat, Apr 6, 2013 at 11:45 AM, Thad Guidry thadgui...@gmail.com wrote: Perhaps the Cherokee webserver might be useful for you to look at it's codebase... and it's implementation of fastcgi.h https://github.com/cherokee/webserver/tree/master/cherokee On Fri, Apr 5, 2013 at 9:13 PM, Andres Osinski andres.osin...@gmail.comwrote: Hi everyone, I've taken an interest in Rust as it fills a niche in programming that I've long been looking to fullfill. I'm primarily a Python web developer, so I wanted to start coding by implementing the FastCGI protocol for Rust. I know that its native task management and socket capabilities are very good, but you never know when it might be handy for someone. I just wanted to know if anyone was familiar with the FCGI protocol, and if there's any reference as to how to manage the packing and unpacking of C data structures, as well as if you know of any implementation for a similar protocol. One small question that I have is that FCGI protocol defines a struct with two char arrays whose length is defined by another field within the struct, and I was wondering how that would be modeled in Rust. Thanks -- Andrés Osinski ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
