the least amount of newcomers.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
+ function ideal) one
would look to start the fix.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
++/JS/other languages would be very useful to
judge.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
rescheduled often.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
need to fetch it
from disk in most cases. On platforms in which devices have a mechanical
component, even trivial accesses can end up very expensive in case of
disk thrashing and/or sleeping disk.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
is freed., looks like they were not keeping the next chunk around.
Indeed this could generate a lot of allocation traffic.
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
another? I'll be in Santa Clara, CA, and I'm free all
the evenings.
-e
I'll be in Brussels.
Cheers,
Yoric
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo
https://mail.mozilla.org/listinfo/rust-dev
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
on this. A
comprehensive datetime library is very important. That said I have not
got any particular ideas or comments.
I have not used Joda time/JSR-310 but the docs look promising and lots
of people seem to recommend it.
Cheers
Gareth
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust
As most people around here, I would prefer avoiding #2 and its magic
variable, unless we can wrap it in a nice syntax extension/macro.
Between #1 and #3, I prefer #1 for the exact reason James Boyden
dislikes it: it lets me concentrate on the most common path, without
having to deal with
,
at least as a coding convention.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust
On 10/23/12 10:01 PM, Graydon Hoare wrote:
On 12-10-23 08:30 AM, David Rajchenbach-Teller wrote:
Finally, I would like to be sure that I understand one thing: as far as
I understand, this mechanism is not designed to handle any kind of
concurrent condition, i.e. a condition raised in one
On Mon Sep 24 22:52:07 2012, Brian Anderson wrote:
On 08/30/2012 11:17 AM, David Rajchenbach-Teller wrote:
Actually, it dawns to me that I could outsource this.
I have put together a bug tracker for student projects that do not fit
in BMO:
https://github.com/Yoric/Mozilla-Student-Projects
implementation of traits,
so I guess this will depend on traits.
* XML
I like it. Perhaps with a nice set of macros for pattern-matching?
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
That looks really cool.
Cheers,
David
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
- (*any item of sum type bar*)
| `bar - (*sum constructor `bar*)
| bar - (*binding*)
It works nicely in practice.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
believe it is.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
(): ...
_: ...
}
I believe that this snippet has a more immediately visible structure
than the original and is easier to read, while the syntax tweak is
trivial to compile.
What do you think?
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
On 6/2/12 6:06 PM, Niko Matsakis wrote:
On 6/1/12 2:59 AM, David Rajchenbach-Teller wrote:
The other problem is that the function may not have enough information
to determine what is locally unrecoverable. I believe that `remove` is
a good example of issues whose recoverability depend
.
The other problem is that the function may not have enough information
to determine what is locally unrecoverable. I believe that `remove` is
a good example of issues whose recoverability depend on the context.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
messy). I do not know the semantics of throwing an exception from JS
to C, but I suspect this is messy.
Now, in Rust, I do not know exactly how to best do this, but I suspect
that we would want calls to JavaScript to return a sum type result/error.
Cheers,
David
--
David Rajchenbach-Teller, PhD
issues as
exceptions, in terms of both performance, semantics and typing (at least
if they are not almost-local returns).
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
and is still idempotent, unrecoverable.
Does this not sit well with you currently?
I will reply once I am sure that I understand the example :)
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
As promised, I have attempted to rewrite my original function |move|
with a mechanism that would let us define issue-handling policies. This
mechanism is inspired by both the current thread and the previous thread
on exceptions, a few months ago.
So far, the result is not too convincing yet, but
and failure cleanup...
Do you know if there is a paper version of this talk?
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
with tracing and logging.
Looks like two distinct things to me. Why couldn't you build a tracing +
logging tool on top of it?
* custom tracing , error and log handlers should be possible and
dynamically configurable,
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev
, but this will
certainly happen.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
language btw, very nicely
done)
http://docs.factorcode.org/content/article-virtual-sequences.html
Not sure I understand. Is that a variant on enumerations or streams?
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital
overloading makes it much easier to misread
code.
So, I personally would not advocate C++-style function overloading.
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev
/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev
On 1/26/12 9:49 PM, Masklinn wrote:
On 2012-01-26, at 20:31 , Graydon Hoare wrote:
On 1/22/2012 6:41 AM, David Rajchenbach-Teller wrote:
As soon as I find some time (and if nobody has done it yet), I'll get
working on a Mac installer. What's the preferred strategy? Should the
Mac installer
-level versioning is not yet operational - future code
will
break unexpectedly.
[1] Contributors to Rust 0.1:
Adam Bozanich
Andreas Gal
Austin Seipp
Ben Striegel
Benjamin Jackman
Brendan Eich
Brian Anderson
Chris Double
Dave Herman
David Rajchenbach-Teller
Elly Fong-Jones
On Mon Dec 5 14:27:18 2011, Marijn Haverbeke wrote:
If bind is staying (there was talk of removing it in favour of lambda
at some point), I think we can do without lambda. But the concept of
shared closures (which is what bind creates) would still be there.
I second Graydon's remark. While syntactically very nice, customizable
operator overloading is the kind of feature that makes it much harder to
understand snippets and, in particular, to review patches.
Now, of course, avoiding operator overloading can be a matter of
project-specific coding
What about the following convention that would at least attract
attention to the fact that we are dealing with custom/overloaded operators?
foo + bar // usual operator
foo `+` bar// regular function + with infix notation
foo `plus` bar // regular function plus with infix
On 11/21/11 7:34 PM, Graydon Hoare wrote:
On 19/11/2011 2:31 PM, David Rajchenbach-Teller wrote:
Let's switch vocabulary, then. Report and Handle are probably less
loaded with implicit meanings.
Sure. Those are good terms. So long as it's clear there are a few
dimensions to the issue
On 11/18/11 8:45 PM, Graydon Hoare wrote:
Woah woah, I'm arriving late here.
We *have* exceptions. They're called 'failure'. The only point about
them is that you can't catch them. For a couple reasons:
I feel that there is a little misunderstanding. If you do not mind, I
would like to
On 11/19/11 1:45 AM, Niko Matsakis wrote:
A #do[] macro which just returns in the case of failure is basically
equivalent to this in practice, I think.
Niko
Not only that, but it plays better with the strengths of Rust.
Cheers,
David
signature.asc
Description: OpenPGP digital
On 11/19/11 1:56 AM, Niko Matsakis wrote:
On Nov 18, 2011, at 4:51 PM, Niko Matsakis wrote:
1. You know exactly what the failure means and an exact, transparent
recovery mode. For this we recommend simply modeling the recovery
mode you want for expected-but-rare circumstances
On Sat Nov 19 20:50:48 2011, Graydon Hoare wrote:
Oh, and a simple example where it does not work: you do not want to deal
with scenario user has suddenly removed the USB key smack in the
middle of your code for, say, serializing your data structure to a
compressed output stream for said key.
On 11/19/11 8:41 PM, Graydon Hoare wrote:
On 19/11/2011 4:02 AM, David Rajchenbach-Teller wrote:
Let's start with a little safety vocabulary, not specifically related to
Rust. It is quite common to have two distinct words: exceptions for
exceptional but expected behavior – that you typically
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu Nov 17 06:10:20 2011, Niko Matsakis wrote:
On Nov 16, 2011, at 11:07 AM, Brian Anderson wrote:
I had thought to redefine result as resultT { ok(T); err(any);
} once that was possible, but I do think maybe creating an exn
type as David
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue Nov 15 15:30:34 2011, Niko Matsakis wrote:
Yes, I was thinking something similar yesterday. Such a pattern
might well be perfect.
I have just submitted a blocker issue
https://github.com/graydon/rust/issues/1176
Syntax-wise, let's write
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/11 12:47 AM, Niko Matsakis wrote:
On Nov 14, 2011, at 12:53 PM, Brian Anderson wrote:
std has a 'result::tT, U' type that I am trying to use for this
purpose. std::io makes use of this now.
Besides exceptions, I do not have a better
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Rusties,
I am currently in the early stages of writing a file system access
library for mozilla-central that might eventually replace some or all
of mozilla-central low-level file access code with something faster
and a little higher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/8/11 5:18 PM, Patrick Walton wrote:
The **new** keyword delimits the constructor inside the class
declaration. It is not used to create instances of the class;
rather, the class declaration results in the introduction of the
constructor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/8/11 6:41 PM, Patrick Walton wrote:
By the way, `alert` was suggested in a bug as a replacement for
log_err (and as a synonym for log(err, ...)), which Marijn and I
like. Has a cute JavaScripty feel to it.
+1 (although any self-respecting JS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Rusties (?),
I am in the process of designing a small rope library for Rust and I
have a few issues wrt `str`. I am a newbie at Rust, so I may be wrong,
but it is my understanding that `str` supports a form of mutability
through an
On Sat Oct 29 09:55:13 2011, Peter Hull wrote:
On Fri, Oct 28, 2011 at 11:25 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
As a newbie, I confirm that both tag and log_err are quite
confusing.
I confirm that print will be much better.
I disagree. I would expect print
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As a newbie, I do not mind either way between importing std::io or
having the function baked in a Pervasives/Prelude module. However, I
concur that log is probably not the right tool for Hello world.
I also concur that names log/log_err do not
54 matches
Mail list logo
