We're on! Live in a few moments.
On Tue, Jan 28, 2014 at 8:09 PM, Erick Tryzelaar
wrote:
> All,
>
> There is a slight delay on getting the Air Mozilla broadcast up and
> running. Once it's up and running, you'll find it here:
>
> https://air.mozilla.org/rust-meetup-january-2014/
>
> I'll send ou
All,
There is a slight delay on getting the Air Mozilla broadcast up and
running. Once it's up and running, you'll find it here:
https://air.mozilla.org/rust-meetup-january-2014/
I'll send out another mail once it's back up.
Thanks,
Erick
On Mon, Jan 27, 2014 at 3:13 PM, Erick Tryzelaar
wro
A small update: I've gotten a resizable version of my disruptor
implementation working, and the performance looks pretty good so far. I
still have a few loose ends to tie up before I push out the changes. I
should have the updated code on GitHub hopefully within a couple of weeks,
depending on how
CTFE would indeed be a very interesting thing to see an experiment on in
Rust.
However, practically, what is the problem that CTFE solves that cannot be
solved by a hygienic macro system (or alternatively, a syntax extension
that has access to the AST)?
My experience with D's CTFE has been largel
On Jan 28, 2014, at 4:01 PM, Pierre Talbot wrote:
> On 01/29/2014 12:45 AM, Kevin Ballard wrote:
>> Yes, I was using #[ctfe] to mean something slightly different than you were.
>> In my case, it meant "mark this function as eligible for CTFE, and impose
>> all the CTFE restrictions". And it doe
On 01/29/2014 12:45 AM, Kevin Ballard wrote:
On Jan 28, 2014, at 3:16 PM, Pierre Talbot wrote:
On 01/28/2014 11:24 PM, Kevin Ballard wrote:
It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any special
anno
On Tue, Jan 28, 2014 at 6:56 PM, Pierre Talbot wrote:
> With support of the compiler, the macros could be implemented in Rust, but
> this is a work that can only be done after CTFE is implemented. So we have
> all the time to invent new syntax and deliberate on the semantic.
Actually, Rust alread
If we drop macro, I can come up with a "simple" solution inspired by the
Lisp quote:
// Return a Rust construction string.
#[ctfe(always)]
fn make_rust_construct() -> ~str {
return ~"5 + 5";
}
#[ctfe(always)]
fn eval(s: ~str) -> ??;
fn main() {
eval(make_rust_construct());
}
We'd rely on
On 29/01/14 10:45, Kevin Ballard wrote:
On Jan 28, 2014, at 3:16 PM, Pierre Talbot wrote:
On 01/28/2014 11:24 PM, Kevin Ballard wrote:
It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any special
annotatio
On Jan 28, 2014, at 3:16 PM, Pierre Talbot wrote:
> On 01/28/2014 11:24 PM, Kevin Ballard wrote:
>> It sounds like you're proposing that arbitrary functions may be eligible for
>> CTFE if they happen to meet all the requirements, without any special
>> annotations. This seems like a bad idea to
The way it is implemented in Rust is by using the libc, but the
requirement #6 says we can't call external function, so implicitly the
problem is solved. I'm agree that it isn't formal, but I can't come up
with a better solution for now.
You made me think of another requirements (so basic that
Our discussion in a recent meeting concluded that statics will not be
allowed to contain types with destructors, and you also won't be able
to move out of static items:
https://github.com/mozilla/rust/issues/10577#issuecomment-32294407
On Tue, Jan 28, 2014 at 3:34 PM, Kevin Ballard wrote:
> At f
That's what I figured. Forbidding unsafe is definitely a good way to keep
things simple starting out. Compile time evaluation can always be extended
later on.
On Tue, Jan 28, 2014 at 3:21 PM, Pierre Talbot wrote:
> On 01/28/2014 11:26 PM, Eric Reed wrote:
>
>> Looks pretty reasonable to me at f
At first glance it seems reasonable to prohibit moving out of a mutable static,
but I'm not sure it really makes sense to try and put restrictions on mutable
statics when we can't make them safe.
-Kevin
On Jan 28, 2014, at 3:26 PM, Niko Matsakis wrote:
> Probably this should yield an error --
Devil's advocate: CTFE and procedural macros would both allow
arbitrary Rust code to be evaluated at compile time. Is there any
sane way to combine them rather than making them separate islands?
Personally, I want a way to run arbitrary code at compile time that
can introspect on and possibly gen
Probably this should yield an error -- I tend to think we should only
permit moves that we cannot enforce from `*` pointers, just to add an
extra barrier.
Niko
On Tue, Jan 28, 2014 at 12:12:23PM -0800, Kevin Ballard wrote:
> Your code is moving the contents of Option<~MyStruct> into the match ar
On 01/28/2014 11:26 PM, Eric Reed wrote:
Looks pretty reasonable to me at first glance.
Out of curiosity, what's the rationale behind forbidding unsafe
functions/blocks?
In the reference manual we can read things such as: "Mutating an
immutable value/reference, if it is not marked as non-free
On 01/28/2014 11:24 PM, Kevin Ballard wrote:
It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any special
annotations. This seems like a bad idea to me. I understand why it's
attractive, but it means that see
Out of that list of requirements, #5 (doesn't perform I/O actions) is the
one that strikes me as least well-defined. Could you elaborate on how you
would enforce it?
Cheers,
Josh
On 28 January 2014 14:15, Pierre Talbot wrote:
> Hi,
>
> The Mozilla foundation proposes research internships [1] a
Looks pretty reasonable to me at first glance.
Out of curiosity, what's the rationale behind forbidding unsafe
functions/blocks?
On Tue, Jan 28, 2014 at 2:15 PM, Pierre Talbot wrote:
> Hi,
>
> The Mozilla foundation proposes research internships [1] and the CTFE
> optimization in the Rust compi
It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any special
annotations. This seems like a bad idea to me. I understand why it's
attractive, but it means that seemingly harmless changes to a function's
implem
Hi,
The Mozilla foundation proposes research internships [1] and the CTFE
optimization in the Rust compiler seems to be a really exciting project.
I wrote a proposal [2] that I'll send with my application and so I'd
like to share it with you and discuss about bringing CTFE inside Rust.
Here
rustpkg is definitely unfinished. It's not clear to me that what it
needs is to be destroyed, rather than finished. That is, there may
well be good reasons; I just haven't seen them so far in this thread.
The concrete points that a few people have made are ones to do with
unfinished pieces of rustp
damned, my gmail client was not up to date, you've got a better answer
already (I got the ref keyword right at least ;))
On Tue, Jan 28, 2014 at 1:00 PM, François-Xavier Bourlet
wrote:
> match global_data {
> Some(data) =>
>
> You should be able to do:
> Some(ref data)
>
> Which wil
match global_data {
Some(data) =>
You should be able to do:
Some(ref data)
Which will take a reference instead of moving the owned pointer.
In the second case (no owned pointer) you are actually copying the
struct everything. Using "ref data" would safe a copy as well.
I might be
On Tuesday, January 28, 2014, Noah Watkins wrote:
> It would be particularly useful to be able to ship a
> closure to be executed remotely.
>
The only language I've seen do this well is Erlang, and it still requires
both nodes have the same version of the same module loaded at the same time.
Thanks, Kevin!
On 29 Jan 2014, at 00:12, Kevin Ballard wrote:
> Your code is moving the contents of Option<~MyStruct> into the match arm. It
> just so happens that this seems to be zeroing out the original pointer in
> memory, and that happens to be the same representation that None does for t
Your code is moving the contents of Option<~MyStruct> into the match arm. It
just so happens that this seems to be zeroing out the original pointer in
memory, and that happens to be the same representation that None does for the
type Option<~MyStruct> (since ~ pointers are non-nullable), so the
No change. JITing code is very unlikely to be added to the language, too
complex. You should instead consider using a scripting language such as lua or
chibi-scheme to send computations across a network
Noah Watkins wrote:
> This question regarding the run-time generation and compilation of
> co
Hi all! I’m not sure is it an error or "static mut" variables misunderstanding
from my side. The source:
struct MyStruct {
val: int
}
static mut global_data: Option<~MyStruct> = None;
fn test_call() {
unsafe {
match global_data {
Some(data) => { println!("We have dat
Any info or idea?
I update from the master and now all my project have the same issue.
If I use rustc I have no problem. I see the thread about rustpkg,
perhaps I should migrate to rustc and cmake?
Philippe
Le 26/01/2014 16:25, Philippe Delrieu a écrit :
Hi,
I have the same problem since 2 o
Keeping it around means maintaining it, and it means tempting people to use it
even though it's deprecated.
My suggestion would be, if you really need rustpkg, then extract it into a
separate repo and maintain it there. But get it out of the mozilla/rust tree.
-Kevin
On Jan 28, 2014, at 11:28
This question regarding the run-time generation and compilation of
code was asked about a year ago.
http://stackoverflow.com/questions/14459647/is-it-possible-to-generate-and-execute-rust-code-at-runtime
I'd like to follow up on that to see if there are any more
developments. It would be parti
Lots of good points in this thread, but I wanted to request deprecation,
but not removal until a better alternative is documented and made
available. Rustpkg works for my needs - I use it every day - but it
definitely needs some TLC.
Thanks!
--
Ian
On Tue, Jan 28, 2014 at 11:46 AM, SiegeLord w
On Mon, Jan 27, 2014 at 11:41 PM, Sebastian Sylvan <
sebastian.syl...@gmail.com> wrote:
>
>
>
> On Mon, Jan 27, 2014 at 9:33 AM, Matthieu Monrocq <
> matthieu.monr...@gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Jan 27, 2014 at 3:39 AM, Brian Anderson wrote:
>>
>>>
>>> Consensus is that the `do` keywor
On 01/27/2014 11:53 PM, Jeremy Ong wrote:
I'm somewhat new to the Rust dev scene. Would anybody care to summarize
roughly what the deficiencies are in the existing system in the interest
of forward progress? It may help seed the discussion for the next effort
as well.
I can only speak for mysel
On Mon, Jan 27, 2014 at 08:33:57PM +0100, Gábor Lehel wrote:
> I think this question has a more general form, namely: when should I pass
> by value and when using &move/&my? I expect this will come up quite a bit
> if we add the latter.
Yes, I agree. The main reason to use `&move/&my` is to permit
On 01/28/2014 04:33 AM, Lee Braiden wrote:
On 28/01/14 08:36, György Andrasek wrote:
I never quite understood the problem `rustpkg` was meant to solve. For
building Rust code, `rustc --out-dir build` is good enough. For
running tests and benchmarks, `rustc` is good enough. For downloading
things
On 01/28/2014 10:33 AM, Lee Braiden wrote:
I agree with this. What I'd want is much more like apt (add
repositories, update lists of available packages from those
repositories, manage priorities between repositories, say that one
repository should be preferred over another for a particular packa
Rubygems is, in my opinion, one of the best examples of package managers
for a programming language out there. I don't use ruby currently but I
recall liking it much more than the competition, at least as of a few years
ago. In no particular order, it features:
- central repository
- optionally sp
I also agree on the task force proposal, it's the right way to capitalize
on past failure and success.
For me, rust-pkg will not success if it doesn't have a proper centralized
repository. That's a debate, the current version explicitely specify the
URL where to download stuff. But things changes,
On 28/01/14 08:36, György Andrasek wrote:
I never quite understood the problem `rustpkg` was meant to solve. For
building Rust code, `rustc --out-dir build` is good enough. For
running tests and benchmarks, `rustc` is good enough. For downloading
things, I still need to feed it a github address
On 28/01/14 19:36, György Andrasek wrote:
I never quite understood the problem `rustpkg` was meant to solve. For
building Rust code, `rustc --out-dir build` is good enough. For
running tests and benchmarks, `rustc` is good enough. For downloading
things, I still need to feed it a github address
I never quite understood the problem `rustpkg` was meant to solve. For
building Rust code, `rustc --out-dir build` is good enough. For running
tests and benchmarks, `rustc` is good enough. For downloading things, I
still need to feed it a github address, which kinda takes away any value
it coul
On Mon, Jan 27, 2014 at 10:20 PM, Val Markovic wrote:
>
> On Jan 27, 2014 8:53 PM, "Jeremy Ong" wrote:
>>
>> I'm somewhat new to the Rust dev scene. Would anybody care to summarize
>> roughly what the deficiencies are in the existing system in the interest of
>> forward progress? It may help seed
45 matches
Mail list logo
