On 2013-05-29, at 07:17 , Alex Crichton wrote:
In my opinion, rusti gets the job done. Yes, having in-memory compiled state
would work a lot better. But I don't know how viable that is. I know for a
fact that a big feature plan is to have the compiler only partially compile
when applicable,
On Tue, May 28, 2013 at 01:48:55PM -0500, Tommy M. McGuire wrote:
The problem I am running into is that the type of the LinearMap's find()
method (Yes, this is 0.6.) is:
fn find(self, k: 'b [u8]) - Option'self 'b [u8]
In other words, the key argument is a borrowed pointer to a borrowed
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
On 13-05-28 09:03 PM, Alex Crichton wrote:
Now this doesn't sound that bad in theory. Normally rusti is for quick
computations. There's not much of a history and nothing really takes a
long time. This quickly becomes a problem though for anything which
uses resources. Let's say that you call
On Wed, May 29, 2013 at 11: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.
This
On Wed, May 29, 2013 at 11: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.
Hi all,
Does using Option incur a runtime cost (like increased memory usage)
compared to a hypothetical case if Rust had a NULL type in the language? Or
does it get optimized away, such that it is akin to using NULL in the first
place (albeit safer of course)?
I have not looked at any
Q patch just recently landed to do that optimization for Option types
containing a pointer. Options wrapping a value type still need an extra
word however in order to distinguish between the Some/None cases though.
On Wednesday, May 29, 2013, Ziad Hatahet wrote:
Hi all,
Does using Option
On Wed, May 29, 2013 at 1:53 PM, Ziad Hatahet hata...@gmail.com wrote:
Hi all,
Does using Option incur a runtime cost (like increased memory usage)
compared to a hypothetical case if Rust had a NULL type in the language? Or
does it get optimized away, such that it is akin to using NULL in the
You will find some more informations in this recent Stackoverflow question :
http://stackoverflow.com/q/16504643/112053
Le mercredi 29 mai 2013 10:53:41 Ziad Hatahet a écrit :
Hi all,
Does using Option incur a runtime cost (like increased memory usage)
compared to a hypothetical case if
Hi Michael,
Just last week I've embarked on a project to fix Rust's debug info emitter
(it's been broken ever since last LLVM version update because of change in
debug metadata format). I've made some progress, but new code still
doesn't have all the features that old code used to have.
I was
How could be integrated the Go language in Rust?
If somebody were to write a Go compiler to be integrated in Rust[1],
which path would be the best one? To create bindings to commands
[568][acgl] [2] or write the SSA library/interpreter [3] in Rust?
[1] to be integrated in other language: I
If you'll ever wish to choose SSA interpretation way - feel free to use my
library to allocate registers for this stuff
https://github.com/indutny/linearscan.rs .
Cheers,
Fedor.
On Wed, May 29, 2013 at 11:51 PM, John Mija jon...@proinbox.com wrote:
How could be integrated the Go language in
On Wed, May 29, 2013 at 3:51 PM, John Mija jon...@proinbox.com wrote:
How could be integrated the Go language in Rust?
[...]
+ It could be used in programs where you want give power to users to run
some tasks, i.e. into a database; today, it's being added JS to some DBMSs
+ To Run web
On 13-05-29 12:51 PM, John Mija wrote:
How could be integrated the Go language in Rust?
To embed a language, it generally needs to present a cdecl callable
interface (= accept C callbacks), and be willing to schedule its
coroutines and IO operations as steps within someone else's event loop.
It
On 05/29/2013 08:01 AM, Michael Wörister 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.
Welcome, and good luck.
On 29.05.2013 17:01, Michael Wörister 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.
Congratulations and good luck!
As for comments
An alternative approach could be taken by using
LLVM's DIBuilder [1] class [...]
Forgotten to add the reference:
[1]
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/DIBuilder.h?view=markup
___
Rust-dev mailing list
Rust-dev@mozilla.org
Hello list,
Currently Rust has different default visibilities in different places:
- `mod` items are private
- `struct` fields and `enum` variants are public
- `trait` methods are public
- `impl` methods are private
- `impls for` are public (by necessity)
I propose to change this to:
-
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;
Thanks for your answer,
El 29/05/13 21:40, Graydon Hoare escribió:
On 13-05-29 12:51 PM, John Mija wrote:
How could be integrated the Go language in Rust?
To embed a language, it generally needs to present a cdecl callable
interface (= accept C callbacks), and be willing to schedule its
Hi,
I have a strong point against it: your crates are going to be christmas
trees of exposed APIs unless you are careful. This has a runtime cost,
increases the risk of breaking the ABI more often than you should, and
often results in unintentional APIs that you may be later beholden to
maintain.
On 5/29/13 2:18 PM, Gábor Lehel wrote:
Hello list,
Currently Rust has different default visibilities in different places:
- `mod` items are private
- `struct` fields and `enum` variants are public
- `trait` methods are public
- `impl` methods are private
- `impls for` are public (by necessity)
Maybe I'm unusual. But in C++ I'm always super-careful (one might say anal
retentive) about keeping my headers as clean of implementation details as
humanly possible. I don't think forgetting a `priv` would ever be an issue.
But I'm not everyone.
On Wed, May 29, 2013 at 11:34 PM, Mikhail Zabaluev
On 13-05-29 02:40 PM, Gábor Lehel wrote:
Maybe I'm unusual. But in C++ I'm always super-careful (one might say
anal retentive) about keeping my headers as clean of implementation
details as humanly possible. I don't think forgetting a `priv` would
ever be an issue. But I'm not everyone.
Hi,
2013/5/30 Gábor Lehel illiss...@gmail.com
Maybe I'm unusual. But in C++ I'm always super-careful (one might say anal
retentive) about keeping my headers as clean of implementation details as
humanly possible. I don't think forgetting a `priv` would ever be an issue.
But I'm not everyone.
On 29 May 2013 17:00, Wojciech Matyjewicz wmatyjew...@fastmail.fm wrote:
The other benefit is that DIBuilder keeps track of what metadata nodes it
has generated and reuses the existing nodes instead of generating identical
ones --- similar functionality from debuginfo.rs could be removed then.
On 05/29/2013 04:55 AM, Niko Matsakis wrote:
On Tue, May 28, 2013 at 01:48:55PM -0500, Tommy M. McGuire wrote:
The problem I am running into is that the type of the LinearMap's find()
method (Yes, this is 0.6.) is:
fn find(self, k: 'b [u8]) - Option'self 'b [u8]
In other words, the key
On Wed, May 29, 2013 at 11:53 PM, Graydon Hoare gray...@mozilla.com wrote:
On 13-05-29 02:40 PM, Gábor Lehel wrote:
Maybe I'm unusual. But in C++ I'm always super-careful (one might say
anal retentive) about keeping my headers as clean of implementation
details as humanly possible. I don't
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.
Hello Everyone,
I've been doing work around optimizations recently, and noticed that libextra
was taking an
inordinate amount of time to build. My investigations led me to find that well
over half the time
spent was on Loop Invariant Code motion, i.e. moving expressions that don't
change out
Indeed, I think it might be useful to embark on a project to review *all*
the uses of #[inline(always)] that currently exist and determine their
necessity. I too have been guilty of using it where #[inline] alone would
suffice.
On Wed, May 29, 2013 at 11:15 PM, James Miller aa...@aatch.net
32 matches
Mail list logo
