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
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
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
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
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 moves
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
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 bander...@mozilla.comwrote:
Consensus is that the `do` keyword is
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
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
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
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 data
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 act
On Tuesday, January 28, 2014, Noah Watkins jayh...@cs.ucsc.edu 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
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
bomb...@gmail.com wrote:
match global_data {
Some(data) =
You should be able to do:
Some(ref data)
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
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 ptal...@hyc.io wrote:
Hi,
The Mozilla foundation proposes research
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
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 arm.
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 ptal...@hyc.io wrote:
On 01/28/2014 11:26 PM, Eric Reed wrote:
Looks pretty reasonable
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 ke...@sb.org
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
On 29/01/14 10:45, Kevin Ballard wrote:
On Jan 28, 2014, at 3:16 PM, Pierre Talbot ptal...@hyc.io 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
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
23 matches
Mail list logo
