Unfortunately, instead of actually fixing the underlying problem […] the
ECMAScript committee seems to have gone with […] which is lighter syntax but
still absurd.
Flaming other languages / committees is very much not the point of
this mailing list. Try to stay on topic and dispassionate.
On 2013-11-14 10:00, Marijn Haverbeke wrote:
Unfortunately, instead of actually fixing the underlying problem […] the
ECMAScript committee seems to have gone with […] which is lighter syntax but
still absurd.
Flaming other languages / committees is very much not the point of
this mailing
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
Hello rust-dev,
I would like to make a comment I feel is important about both the Rust
tutorial and manual. Please don't misunderstand me, no flame here, I
am sending this message to help. I think good docs are extremely
important to increase the size of a community, and in particular make
more
I would defineltly like to see a clone of the python tutorial because it
really does it so well going inch by inch building up what way things work
i am not a web developer but would love to write content i wonder is it
possible to start a github project for this using sphinx i think it uses
isn't
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
I've never setup such a system. I imagine it'd need some
infrastructure in place.
On Thu, Nov 14, 2013 at 11:21 AM, Thad Guidry thadgui...@gmail.com wrote:
Corey,
Could we get that comments/feedback ability into the tutorial easily ? I
agree that would be a good start in improving things.
Good morning Rustics,
The second Bay Area meetup is happening in 6 days:
http://www.meetup.com/Rust-Bay-Area/events/143439552/
Patrick will be giving a presentation about Sprocketnes along with a few
others giving some lightning talks. I'd like to start planning for the next
one in
This is to some extent in flux (see bug #10337). But the branch I am
working on actually reports *both* usages as errors. The correct code
would be:
*p + n
n + *p
Basically, a binary operator like `l + r` is translated to something
similar to the following (which assumes universal function
I would love helping on this matter, I'm use to setting up automatic
documentation generation (rst, sphinx, doxygen,...).
-
Gaetan
2013/11/14 Philip Herron redbr...@gcc.gnu.org
I would defineltly like to see a clone of the python tutorial because it
really does it so well going inch by
I would welcome such an effort, and suggest that it live as its own
project, outside of the Rust repo. We really aren't set up currently to
handle rapid and frequent documentation changes. Once it gets to a
reasonable level of maturity we could then give it a mention from the main
tutorial, and
And by replace I mean we could relegate the current tutorial to an
advanced tutorial or somesuch.
On Thu, Nov 14, 2013 at 12:30 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
I would welcome such an effort, and suggest that it live as its own
project, outside of the Rust repo. We really
do you have a buildbot or jenkins for the rust ?
I don't think travis could push html pages to a remote repository, do it?
-
Gaetan
2013/11/14 Benjamin Striegel ben.strie...@gmail.com
I would welcome such an effort, and suggest that it live as its own
project, outside of the Rust repo.
I have a question about the two files libextra and libstd that are
installed by rust compiler.
Can they be called by any normal average program?
If so, shouldn't we document how?
If this has no sense, I suggest to rename them to something like
libruststd or librustextra to avoid naming conflict
good :)
so, what is missing to have an automatic generation of html page from a
github page?
-
Gaetan
2013/11/14 Corey Richardson co...@octayn.net
Travis could, but then anyone could (since the travis.yml is public
and it'd need credentials to the repo). We have a buildbot,
We *do* do automatic generation. It uses the markdown in `doc`.
tutorial.md, and rust.md is the manual.
On Thu, Nov 14, 2013 at 12:51 PM, Gaetan gae...@xeberon.net wrote:
good :)
so, what is missing to have an automatic generation of html page from a
github page?
-
Gaetan
Hi
I was trying to install RUST on my ubuntu local system.I could not complete
after make make install.I also tried sudo make install.Both of them
failed .I got this note;Bug reported Compiler hitting unexpected failure
path
https://gist.github.com/Tessie/7470406
Regards
Tessy
These standard libraries are already packaged for use and documented on the
homepage. The import for std is implied, and for the second you just need
this:
extern mod extra;
Cheers,
Kevin
On Thu, Nov 14, 2013 at 9:50 AM, Gaetan gae...@xeberon.net wrote:
I have a question about the two
Definitely looks like an internal compiler error (a.k.a. an ICE). If you
happen to have the time, run it again with more logging (like that error
message says) and file an issue on GitHub! :D
Kevin
On Thu, Nov 14, 2013 at 9:57 AM, tessy joseph tessyjoseph1...@gmail.comwrote:
Hi
I was
It looks like you're compiling a fairly old version of the compiler, I
would recommend that you update to the master branch instead of using
older copies (we're a fast-moving target right now!)
On Thu, Nov 14, 2013 at 9:57 AM, tessy joseph tessyjoseph1...@gmail.com wrote:
Hi
I was trying to
I was initially concerned, like you, about putting such generic-sounding
libraries in /usr/local/lib, but of course that’s not the full name. On the
current machine (whose rust is slightly out of date, so this may not match the
name you have), libstd is actually
I added https://github.com/mozilla/rust/issues/10491 which links to
https://github.com/mozilla/rust/issues/9728 to propose that single
inheritance can co-exist and be compatible with anonymous fields, achieving
the best of both worlds.
___
Rust-dev
I completely share your views, Daniel.
[Would have expressed them myself if I did not know (from experience) that
constructive critics by me (in english) usually are mistaken or misunderstood:
people just deny, argue, or reply violently. But you do a good job, here, in my
opinion.]
Denis
Could there be a kind of rust-tutorial-in-progress wiki page? (with required
subscription to edit). Seems to me the easiest path to cooperative edition.
Then, just have a single person responsible for regularly pushing the 'in
progress' version as the 'offical' one, whenever its state is ok.
Honestly, I am not sure tutorial quality and automatic generation live
well together. We hire tech evangelists for their ability to present well
information and make messages percolate better, and similarly good doc
requires good tech writers who only do that.
As I said earlier, a tutorial is
On 15/11/13 08:08, Daniel Glazman wrote:
Honestly, I am not sure tutorial quality and automatic generation live
well together. We hire tech evangelists for their ability to present well
information and make messages percolate better, and similarly good doc
requires good tech writers who only do
On Thu, Nov 14, 2013 at 5:27 AM, Igor Bukanov i...@mir2.org wrote:
On 14 November 2013 06:42, Daniel Micay danielmi...@gmail.com wrote:
There's a link to the Microsoft documentation on the
implementation (replacing Windows fibers) we could be using right now.
It's not entirely necessary to
On Wed, Nov 13, 2013 at 10:46 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
On 11/13/13 9:08 PM, Ben Noordhuis wrote:
Libuv maintainer here. Libuv's current approach to dealing with
blocking I/O is fairly crude: it offloads everything to a rather
unsophisticated thread pool. There
Hi all,
My program starts a bunch of tasks, then I want the main task to both
receive ctrl-c signals and receive results from the children. The
signal will come from a std::rt::io::signal::Listener's port, which is
an std::comm::PortSignum. The child results will come from a
Why couldn't we implement multiple inheritance like this:
Traits provide the functionality, and a struct provides the data for those
traits to implement their functionality.
It would look like this:
trait Inflate {
fn get_radius's('s mut self) - 's mut int;
fn inflate_by(mut self,
On 11/11/2013 03:52 PM, Gaetan wrote:
Can we have Two rust?
The first one would be easy to learn, easy to read, and do most of ones
would expect: on demand garbage collector, traits, Owned pointers,...
The second one would include all advanced feature we actually don t
need everyday
This
On 2013-11-15, at 2:09, Tommi rusty.ga...@icloud.com wrote:
trait Inflate {
fn get_radius's('s mut self) - 's mut int;
fn inflate_by(mut self, amount: int) {
*self.get_radius() += amount;
}
}
trait Flatten {
fn get_radius's('s mut self) - 's mut int;
fn
On Thu, Nov 14, 2013 at 7:31 PM, Nathan Myers n...@cantrip.org wrote:
On 11/11/2013 03:52 PM, Gaetan wrote:
Can we have Two rust?
The first one would be easy to learn, easy to read, and do most of ones
would expect: on demand garbage collector, traits, Owned pointers,...
The second one
On 11/15/13 9:51 AM, Daniel Micay wrote:
The same is true for 1:1 vs. M:N threading. If a task doesn't map 1:1
to a thread ID and thread-local data, support for C libraries using
thread-local data will always be stuck with an inferior API to C/C++.
Unless you pin the task, no?
There's also
On Thu, Nov 14, 2013 at 7:53 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/15/13 9:51 AM, Daniel Micay wrote:
The same is true for 1:1 vs. M:N threading. If a task doesn't map 1:1
to a thread ID and thread-local data, support for C libraries using
thread-local data will always be stuck
On 11/15/13 9:51 AM, Daniel Micay wrote:
The reason for Rust not simply supporting (almost) every architecture
that LLVM supports out-of-the-box is M:N threading.
I take issue with this. The *language* supports almost every
architecture that LLVM supports. The *runtime* is just part of the
On 11/15/13 10:00 AM, Daniel Micay wrote:
If you pin the task and other tasks aren't allowed to use the thread,
it would work. The library would have to do this in all the entry
points to provide safety and there would have to be no way of
unpinning a task in safe code or at least a separate
On 11/14/2013 07:03 AM, Daniel Glazman wrote:
Hello rust-dev,
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
On Thu, Nov 14, 2013 at 8:02 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/15/13 9:51 AM, Daniel Micay wrote:
The reason for Rust not simply supporting (almost) every architecture
that LLVM supports out-of-the-box is M:N threading.
I take issue with this. The *language* supports
On 11/14/2013 04:03 PM, Diego Ongaro wrote:
Hi all,
My program starts a bunch of tasks, then I want the main task to both
receive ctrl-c signals and receive results from the children. The
signal will come from a std::rt::io::signal::Listener's port, which is
an std::comm::PortSignum. The child
On 2013-11-15, at 2:40, Tommi rusty.ga...@icloud.com wrote:
On 2013-11-15, at 2:09, Tommi rusty.ga...@icloud.com wrote:
trait Inflate {
fn get_radius's('s mut self) - 's mut int;
fn inflate_by(mut self, amount: int) {
*self.get_radius() += amount;
}
}
trait
On 2013-11-15, at 3:23, Tommi rusty.ga...@icloud.com wrote:
On 2013-11-15, at 2:40, Tommi rusty.ga...@icloud.com wrote:
On 2013-11-15, at 2:09, Tommi rusty.ga...@icloud.com wrote:
trait Inflate {
fn get_radius's('s mut self) - 's mut int;
fn inflate_by(mut self, amount: int) {
On 11/14/13 4:31 PM, Nathan Myers wrote:
On 11/11/2013 03:52 PM, Gaetan wrote:
Can we have Two rust?
The first one would be easy to learn, easy to read, and do most of ones
would expect: on demand garbage collector, traits, Owned pointers,...
The second one would include all advanced
On 11/15/13 1:40 PM, Paul Nathan wrote:
* Linux is not the only platform that matters. I would actually argue
that other operating systems, in particular the embedded RTOS space,
are the OS platforms that need to be held up as platforms to be careful
to map against. Names of such operating
On Thu, Nov 14, 2013 at 11:40 PM, Paul Nathan
pnat...@vandals.uidaho.edu wrote:
* Linux is not the only platform that matters. I would actually argue
that other operating systems, in particular the embedded RTOS space,
are the OS platforms that need to be held up as platforms to be careful
On 11/15/13 1:54 PM, Daniel Micay wrote:
An alternative library is a far better situation than not having good
real-time/embedded/freestanding support. I'll have a rejected pull
request or RFC to point at for any divergence taken by rust-core, and
it won't make any pointless bikeshed changes
On 11/14/13 8:54 PM, Daniel Micay wrote:
On Thu, Nov 14, 2013 at 11:40 PM, Paul Nathan
pnat...@vandals.uidaho.edu wrote:
* Linux is not the only platform that matters. I would actually argue
that other operating systems, in particular the embedded RTOS space,
are the OS platforms that need
In your code, when providing a default implementation for `inflate_by`, you
are invoking the trait (hence virtual) method `get_radius`. If the
compiler compiles `inflate_by` when seeing just the `Inflate` source code,
then this must be translated to an indirect call through the vtable.
The point
On 11/14/2013 09:25 PM, Tommi wrote:
trait Inflate {
fn get_radius's('s mut self) - 's mut int;
fn inflate_by(mut self, amount: int) {
*self.get_radius() += amount;
}
}
[...]
Third time's the charm. One more detail was still missing:
struct Inflate {
virtual void
49 matches
Mail list logo
