Re: [rust-dev] Migrating libs out of rust-lang/rust
On 29/07/14 23:30, Alex Crichton wrote:
[...]
We plan to implement any necessary infrastructure to ensure that the crates
move out of the rust repository maintain the same level of quality they
currently have.
Will these crates’ documentation be available online?
In rust-url, rust-cssparser, and Servo, I have Travis-CI setup to
generate documentation with rustdoc and, for successful builds on
master, upload it to GitHub Pages. The end result looks like this:
http://servo.github.io/rust-cssparser/cssparser/index.html
See at the end of this email for how this works.
Long term, I’d like Rust to have an official package index, like
Python’s PyPI: https://pypi.python.org/
PyPI provides free hosting for documentation of Python projects. I’d
like Rust to have something like this too. GitHub Pages works and exists
now, but I’m not a fan of generated files in the source repository, even
in a separate branch.
To this extent, the current process for moving a crate out of the standard
distribution will be as follows:
1. A member of the core team will be contacted to create the repository
`rust-lang/$foo`.
2. A PR will be made against `rust-lang/$foo`
I’ve just checked: GitHub does not allow forking (and therefore making
PRs to) an empty repository, so the person creating the repository will
have to at least check the Initialize this repository with a README
checkbox to make a dummy first commit.
with the current copy of the
code from `rust-lang/rust`. This PR will be expected to have the
following source structure:
* Cargo.toml - a manifest to build this repo as a cargo package
* .travis.yml - configuration to run automated tests on travis. A
sample can be found for hexfloat [1]
* LICENSE-{MIT,APACHE} - copied over from rust-lang/rust
* src/ - the same source structure as the folder in rust-lang/rust
This should also include a README.md file containing at least of copy of
the crate’s docstring.
3. A PR will be made against `rust-lang/rust` which will flag the relevant
library as `#[deprecated]` with a message pointing at `rust-lang/$foo`
In order to ensure that these repositories continue to stay up to date, we
will have the following process in place:
1. Each repository will be hooked up to Travis CI and will be built each
night once the new nightlies are available.
How will this be achieve? http://www.rust-ci.org/ does it, but I’d like
to see something more official and tied to the rust-lang.org binary
nightlies rather than the Ubuntu PPA.
[...]
Regarding documentation on GitHub pages mentioned earlier, the script
doing it looks like this:
https://github.com/servo/rust-cssparser/blob/331e5695dc/.travis.yml
The `meta http-equiv=refresh ...` line is so that the URL
http://servo.github.io/rust-cssparser/ is not a 404 error. (rustdoc does
not generate anything there.)
ghp-import resets a git branch (defaults to gh-pages) to contain exactly
what’s in a given directory, regardless of what the branch previously
contained.
The secure line is created with `travis encrypt -r
servo/rust-cssparser TOKEN=[hex string]`, where [hex string] is a GitHub
access token for a user with push access to the repository. (I created
https://github.com/rustdoc for this purpose.)
http://docs.travis-ci.com/user/encryption-keys/
https://help.github.com/articles/creating-an-access-token-for-command-line-use
--
Simon Sapin
___
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
Ok, I got the basic going with a temporary for of `libsemver` here:
- https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706
- https://github.com/errordeveloper/rust-libsemver
Few questions:
- should I bother with enabling OS X beta on Travis?
- what naming convetion we gonna use? shall it be `rust-lib{name}`?
On 30 July 2014 10:44, Simon Sapin simon.sa...@exyr.org wrote:
Long term, I'd like Rust to have an official package index, like Python's
PyPI: https://pypi.python.org/
I though Cargo had an early version of this... Although, I don't think
this is even needed. People should just use git (or other SCM) in a
decent fashion, with a branch policy and tagging. If you have a
central index, it's a point of failure and you may end-up with
bullshit like mirroring.
PyPI provides free hosting for documentation of Python projects. I'd like
Rust to have something like this too. GitHub Pages works and exists now, but
I'm not a fan of generated files in the source repository, even in a
separate branch.
I think godoc.org (http://godoc.org/) is pretty sweet, although it
doesn't handle revisions, as I can see. Well, neither does `go get`.
Anyhow, I think rdoc.info (http://rdoc.info/) is probably the most
extensive implementation of an auto-magic docs site.
I've just checked: GitHub does not allow forking (and therefore making PRs
to) an empty repository, so the person creating the repository will have to
at least check the Initialize this repository with a README checkbox to
make a dummy first commit.
Yeah, could someone create empty repos for all the libs we agreed to pull out?
How will this be achieve? http://www.rust-ci.org/ does it, but I'd like to
see something more official and tied to the rust-lang.org binary nightlies
rather than the Ubuntu PPA.
Hm... I think we should complete the splitting part, and then look back at this.
Perhaps, in the library repos, we can create tags with revision of the
compiler that it passed the test on. Crago, in turns, could pick
lookup these tags and checkout the relevant version. How do people
find this idea? Does Cargo even handle compiler versions at the
moment? If not, it's certainly an important feature to add.
Regarding documentation on GitHub pages mentioned earlier, the script doing
it looks like this:
https://github.com/servo/rust-cssparser/blob/331e5695dc/.travis.yml
I pick some bit of yours into mine and we can hopefully come up with a
simple template for everyone.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Rust ported to DragonFlyBSD
Am 29.07.2014 um 20:37 schrieb Rob Latham: After trying to cross-compile Rust by specifying --target x86_64-pc-dragonfly-elf to Rust’s own configure script and spending numerous hours just to note that the build fails... Howdy, fellow crazy cross-compiling person. Did you by any chance come across my message from a week or so ago? One response seemed likely to help you if you were encountering a specific kind of build failure: https://mail.mozilla.org/pipermail/rust-dev/2014-July/010827.html what other errors were you encountering with the --target approach? When building the related C libraries you also need to specify the --sysroot to point to the DragonFly tree, otherwise it's building the libraries targeted at DragonFly but with Linux header files, which clearly is *wrong*. Actually I wasn't able to cross-compile LLVM. Also when using the --target approach, I always had to wait for hours until it finished the Linux (host) build before it started to build the target. I think I was just waiting too much time for compiles to finish. If someone else figures out how to cross-compile to DragonFly with the --target approach I am happy to know :). Regards, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Rust ported to DragonFlyBSD
On Wed, Jul 30, 2014 at 8:44 AM, Michael Neumann mneum...@ntecs.de wrote: Am 29.07.2014 um 20:37 schrieb Rob Latham: what other errors were you encountering with the --target approach? When building the related C libraries you also need to specify the --sysroot to point to the DragonFly tree, otherwise it's building the libraries targeted at DragonFly but with Linux header files, which clearly is *wrong*. I'd set this up in mk/platform.mk. Check out how arm-apple-ios does it: CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2/dev/null) CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK) -mios-version-min=7.0 CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS) https://github.com/rust-lang/rust/blob/master/mk/platform.mk#L158 Actually I wasn't able to cross-compile LLVM. Also when using the --target approach, I always had to wait for hours until it finished the Linux (host) build before it started to build the target. I think I was just waiting too much time for compiles to finish. If someone else figures out how to cross-compile to DragonFly with the --target approach I am happy to know :). I agree it takes a while. ccache is a big help but it still takes a while. ==rob ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Rust ported to DragonFlyBSD
Am 30.07.2014 um 16:04 schrieb Rob Latham: On Wed, Jul 30, 2014 at 8:44 AM, Michael Neumann mneum...@ntecs.de wrote: Am 29.07.2014 um 20:37 schrieb Rob Latham: what other errors were you encountering with the --target approach? When building the related C libraries you also need to specify the --sysroot to point to the DragonFly tree, otherwise it's building the libraries targeted at DragonFly but with Linux header files, which clearly is *wrong*. I'd set this up in mk/platform.mk. Check out how arm-apple-ios does it: CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2/dev/null) CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK) -mios-version-min=7.0 CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS) https://github.com/rust-lang/rust/blob/master/mk/platform.mk#L158 I tried this as you can see here [1]. But you have to consider that Mac OS X comes with an iphone SDK while Linux does not come with DragonFly SDK :D. I think no-one ever tried to cross-compile a program for DragonFly :). [1]: https://github.com/mneumann/rust/commit/ab1124980f97558af87b789a1c0772bfa7e23704 Regards, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Rust ported to DragonFlyBSD
Hi, Also when using the --target approach, I always had to wait for hours until it finished the Linux (host) build before it started to build the target. Yep, `--target` approach can be extremely exhausting. One pretty useful dirty trick in this case is to build it once for host and play a lot with `touch -r`. It might be used to recompile only for target when you have changes in mk/* or src/lib*. For example, if you've changed src/libstd/somefile.rs, you can later on do: `touch -r src/libstd/lib.rs src/libstd/somefile.rs` If libstd was compiled successfully before it is required also to delete stamp: `rm build_dir/host_triple/stage2/lib/rustlib/target_triple/lib/stamp.std` and `make -j4` it again, just for target, no waiting for host :-) Used it a lot while porting for iOS and while this message is definitely late for Dragonfly - I hope it will be useful for others who might be interested in porting to platforms which are easier accessible through `--target` approach. -- Valerii signature.asc Description: OpenPGP digital signature ___ 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
We plan to implement any necessary infrastructure to ensure that the crates move out of the rust repository maintain the same level of quality they currently have. Will these crates’ documentation be available online? At this time there are no plans for this, but we're certainly open to options! The need for these is a little less pressing now that `cargo doc` is implemented, but this is still a very important aspect to these crates. Long term, I’d like Rust to have an official package index, like Python’s PyPI: https://pypi.python.org/ We would as well! This will manifest itself in the form of a central package registry which cargo will also use for downloading remote packages and such. To this extent, the current process for moving a crate out of the standard distribution will be as follows: 1. A member of the core team will be contacted to create the repository `rust-lang/$foo`. 2. A PR will be made against `rust-lang/$foo` I’ve just checked: GitHub does not allow forking (and therefore making PRs to) an empty repository, so the person creating the repository will have to at least check the Initialize this repository with a README checkbox to make a dummy first commit. Aha, thanks! 3. A PR will be made against `rust-lang/rust` which will flag the relevant library as `#[deprecated]` with a message pointing at `rust-lang/$foo` In order to ensure that these repositories continue to stay up to date, we will have the following process in place: 1. Each repository will be hooked up to Travis CI and will be built each night once the new nightlies are available. How will this be achieve? http://www.rust-ci.org/ does it, but I’d like to see something more official and tied to the rust-lang.org binary nightlies rather than the Ubuntu PPA. There's a cron job running which will trigger each build each night after the nightlies have finished building, and the .travis.yml script for these repos are all wired to nightlies rather than the PPA. ___ 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
Ok, I got the basic going with a temporary for of `libsemver` here:
- https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706
- https://github.com/errordeveloper/rust-libsemver
Awesome! I've created a new repo for you to make a PR against:
https://github.com/rust-lang/semver
- should I bother with enabling OS X beta on Travis?
Not at this time.
- what naming convetion we gonna use? shall it be `rust-lib{name}`?
rust-lang/{name}
I've just checked: GitHub does not allow forking (and therefore making PRs
to) an empty repository, so the person creating the repository will have to
at least check the Initialize this repository with a README checkbox to
make a dummy first commit.
Yeah, could someone create empty repos for all the libs we agreed to pull out?
This will be done on a case-by-case basis, feel free to just ping me
or others on IRC and we'll make a repo!
___
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
I'd like to suggest - assuming it's not implied - that all aforementioned
PRs should preserve history to date, rather than just having a copy of the
files as they are at present.
Decent walkthrough using a subtree merge -
http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository/17864475#17864475
-Neil
On Tue, Jul 29, 2014 at 6:30 PM, Alex Crichton a...@crichton.co wrote:
Now that cargo is starting to become a larger part of the Rust ecosystem
it's time for some of the crates as part of the standard distribution to
move out of the main rust repository. This movement has been planned for
quite some time now, and it has only recently become possible with the
advent of cargo.
Starting today, we'd like to evolve crates not needed by rustc itself
outside of the compiler wherever possible. This will reduce cycle time on
development of these libraries, allow them to develop independently from
rustc, and hopefully allow them to be more focused in their target goals.
The process of moving crates out of the standard distribution will be an
ongoing and evolving one. We currently have the benefit of being able to
move the entire distribution forward in one atomic step with everything in
one repository, but this quickly becomes infeasible with many repositories.
We plan to implement any necessary infrastructure to ensure that the crates
move out of the rust repository maintain the same level of quality they
currently have.
To this extent, the current process for moving a crate out of the standard
distribution will be as follows:
1. A member of the core team will be contacted to create the repository
`rust-lang/$foo`.
2. A PR will be made against `rust-lang/$foo` with the current copy of the
code from `rust-lang/rust`. This PR will be expected to have the
following source structure:
* Cargo.toml - a manifest to build this repo as a cargo package
* .travis.yml - configuration to run automated tests on travis. A
sample can be found for hexfloat [1]
* LICENSE-{MIT,APACHE} - copied over from rust-lang/rust
* src/ - the same source structure as the folder in rust-lang/rust
3. A PR will be made against `rust-lang/rust` which will flag the relevant
library as `#[deprecated]` with a message pointing at `rust-lang/$foo`
In order to ensure that these repositories continue to stay up to date, we
will have the following process in place:
1. Each repository will be hooked up to Travis CI and will be built each
night once the new nightlies are available.
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
___
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] Migrating libs out of rust-lang/rust
On 30/07/14 15:59, Alex Crichton wrote: We plan to implement any necessary infrastructure to ensure that the crates move out of the rust repository maintain the same level of quality they currently have. Will these crates’ documentation be available online? At this time there are no plans for this, but we're certainly open to options! This sounds like a significant regression :/ The need for these is a little less pressing now that `cargo doc` is implemented, but this is still a very important aspect to these crates. Yeah, we can easily have Travis run `cargo doc`. The question is where to host the result. There's a cron job running which will trigger each build each night after the nightlies have finished building, and the .travis.yml script for these repos are all wired to nightlies rather than the PPA. Could the source code for this cron job be published, with instructions on how to get API keys or whatever Travis wants? I tried https://github.com/patrickkettner/travis-ping , but only got a mysterious error messages and didn’t feel like debugging that code. -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
Gregor,
I think the simple answer is that if your function needs to be broadly
extensible in the future and to have specialization, it needs to be
designed in the trait fashion, per the remarks earlier.
On Thu, Jul 24, 2014 at 5:46 PM, Gregor Cramer rema...@gmx.net wrote:
Hello Rust folk!
I am new to Rust, and I have doubts concerning current language concepts.
One example: in module ::std::num function pow() is defined:
pub fn powT: One + MulT, T(mut base: T, mut exp: uint) - T {
if exp == 1 { base }
else {
let mut acc = one::T();
while exp 0 {
if (exp 1) == 1 {
acc = acc * base;
}
base = base * base;
exp = exp 1;
}
acc
}
}
In general this implementation is ok, but not really usable with BigInt. Of
course, the call ':.std::num::pow(a, 1000)', 'a' is a BigInt, works. But
this
implementation is not adequate for big integers. Firstly, too many memory
allocations during the computation (a specialized version can avoid these
memory allocations), secondly, for big integers a specialized function for
squaring (base * base) has to be used, because squaring can be done quite
more efficient than multiplication (with big integers). So this function
is much
too slow and has to be overloaded, but:
1. Overloading is not supported (even the archaic C++ is providing this).
2. The footprint 'base: T' is not 100% suitable, for big integers the
function
definition
fn pow(base: BigInt, mut exp: uint) - BigInt
would be more appropriate, because the argument 'base' needs not to be
modified (or reassigned), and a call by reference (avoiding a superfluous
memory allocation) is more efficient in this case.
Of cource, a specialized version of pow() could be implemented in trait
BigInt, but this is only a workaround. And if a user only knows
::std::num::pow(), he will use an inappropriate implementation without
being aware of this.
Probably in this case it might be a solution to move pow() into a trait,
but
I'm speaking about a general problem. Rust 1.0 will be released, and
someone
is developing a new module for version 1.1. But some of the functions in
1.0
are inadequate for the new module, how to solve this without changing the
API
in 1.1? I think that function overloading may help in some cases, but the
problem with inappropriate footprints remains. In my opinion this
thing with the footprints (reference or not if the real type is unknown -
that's why the concept with 'const' in C++ exists) is a conceptual design
issue, but probably I do not yet fully understand Rust.
BTW: the functions next_power_of_two(), and checked_next_power_of_two()
are only defined for primitives (trait Primitive), but should also be
applicable for big integers, I think .
C heers,
Gregor
___
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] August 21st SF Bay Area Rust Meetup - Updates from the Rust Team
Are you guys filming it? On 30 July 2014 01:53, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Hello Rustillians! I'm pleased to announce the next Bay Area Rust Meetup on Thursday, August 21, 2014, at Mozilla's San Francisco office: Please sign up here if you wish to attend: http://www.meetup.com/Rust-Bay-Area/events/191293242/ This is a unique meetup because we will be having the full Mozilla Rust team in town in attendance and speaking about what they've been working on. Here is our lineup of speakers: * Alex Crichton: Cargo: forged in a crucible of Rust * Niko Matsakis: TBD * Patrick Walton - Explaining the Borrowcheck (or TBD). * Aaron Turon: The intersection of new language features and libraries. If you cannot attend in person, we will have the talk livestreamed on Air Mozilla (https://air.mozilla.org/bay-area-rust-meetup-august-2014/). As always, Mozilla will be graciously providing food and drink. I hope you can all make it! -Erick PS: The brand new San Francisco Rust Hacknights meetup group is also hosting a hacknight happening that same week on August 19th: http://www.meetup.com/SF-Rust-Hacknights/events/194585552/ Don't miss out on it! ___ 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] August 21st SF Bay Area Rust Meetup - Updates from the Rust Team
We will be live streaming the August meetup. Tomorrow's meetup will be video taped then uploaded to Air Mozilla. On Wed, Jul 30, 2014 at 3:54 PM, Ilya Dmitrichenko errordevelo...@gmail.com wrote: Are you guys filming it? On 30 July 2014 01:53, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Hello Rustillians! I'm pleased to announce the next Bay Area Rust Meetup on Thursday, August 21, 2014, at Mozilla's San Francisco office: Please sign up here if you wish to attend: http://www.meetup.com/Rust-Bay-Area/events/191293242/ This is a unique meetup because we will be having the full Mozilla Rust team in town in attendance and speaking about what they've been working on. Here is our lineup of speakers: * Alex Crichton: Cargo: forged in a crucible of Rust * Niko Matsakis: TBD * Patrick Walton - Explaining the Borrowcheck (or TBD). * Aaron Turon: The intersection of new language features and libraries. If you cannot attend in person, we will have the talk livestreamed on Air Mozilla (https://air.mozilla.org/bay-area-rust-meetup-august-2014/). As always, Mozilla will be graciously providing food and drink. I hope you can all make it! -Erick PS: The brand new San Francisco Rust Hacknights meetup group is also hosting a hacknight happening that same week on August 19th: http://www.meetup.com/SF-Rust-Hacknights/events/194585552/ Don't miss out on it! ___ 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] Place for discussions
Hello, I'm following rust for quite a while, but the discussions are more and more distributed between different places. The mailing list was probably first, then with more user attention reddit and StackOverflow, and now the discourse forum. I understand that StackOverflow and Reddit are more for users, not developers, but the discourse forum seems mostly redundant. What's the reason for that split? Is the mailing list deprecated? Which one is the future? I for myself prefer the mailing list because of the gmane NNTP service, I can use my usual usenet software and have all my forums in one place. Tobi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Place for discussions
Slightly OT, but there are user setting switches you can set in Discourse that will make it act more like an email list. On Jul 30, 2014 8:08 PM, Tobias Müller trop...@bluewin.ch wrote: Hello, I'm following rust for quite a while, but the discussions are more and more distributed between different places. The mailing list was probably first, then with more user attention reddit and StackOverflow, and now the discourse forum. I understand that StackOverflow and Reddit are more for users, not developers, but the discourse forum seems mostly redundant. What's the reason for that split? Is the mailing list deprecated? Which one is the future? I for myself prefer the mailing list because of the gmane NNTP service, I can use my usual usenet software and have all my forums in one place. Tobi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
