On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co wrote:
Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but
I think that it should be important to be able to fail! and have the
repl state intact afterwards.
Agreed. I'm convinced that fail! should result in
Perhaps the best thing is just to fork(2), so we get a new (OS level)
process that has copy-on-write (virtual) memory, and if the compilation +
run succeeds in the child, then have the child take over. Otherwise the
child dies with an fail! + location message, and we return to the parent
The way that Lua does raw strings is also fairly nifty. Check out
http://www.lua.org/manual/5.2/manual.html, section 3.1, or, in short:
- Strings can be delimited by [===[, with any number of equals signs.
The corresponding closing delimiter must match the original number of
equals signs.
- No
On 2013-09-19, at 23:45 , Kevin Ballard wrote:
Yes I know, but in my (rather limited) experience with Python, triple-quoted
strings are typically used for docstrings. It was just an example anyway.
They're also commonly used for multiline strings as single-quoted strings don't
require it.
On Sep 20, 2013, at 1:13 AM, Masklinn maskl...@masklinn.net wrote:
Also,
windows file paths
windows paths can also use forward slashes so that's not a very
interesting justification.
Not always. UNC paths must start with \\ (in my testing, //foo/bar/baz is
not interpreted as a UNC
If I need to embed both ''' and in a string, I'm out of luck.
The chance of that is as remote as can be. I've never seen or heard of
it happen. And mind, the issue must happen *in a rawstring* which is
even more unlikely.
You should note that, as soon as you include something in the
On 2013-09-20, at 10:26 , Marijn Haverbeke wrote:
If I need to embed both ''' and in a string, I'm out of luck.
The chance of that is as remote as can be. I've never seen or heard of
it happen. And mind, the issue must happen *in a rawstring* which is
even more unlikely.
You should note
Out of all the mentioned syntaxes, Python's seems simple and easy (and the
corner cases appear to be fairly unlikely for the actual use cases for raw
strings), Ruby's seems very powerful and if a couple of restrictions are
added could probably fit well, and Lua's seem very well designed by
Python's has really stupid handling of backslashes, and I really don't like how
it cannot represent all valid strings. I'd really prefer not to make that same
mistake.
Ruby's syntax cannot be used because % lexes as an operator.
Of the 3, Lua's is probably the best, although it's a bit
I really like the API you are proposing. In particular, the error handling is
close to what I was expecting from such an API.
I have some remarks, though.
Is there a reason for encoders and decoders to not be reusable ? I think it
would be reasonable to specify that they get back to their
Le 20/09/2013 10:18, Olivier Renaud a écrit :
I really like the API you are proposing. In particular, the error handling is
close to what I was expecting from such an API.
I have some remarks, though.
Is there a reason for encoders and decoders to not be reusable ? I think it
would be
Hi all, I have a question which I'm sure must have already been discussed
and dealt with, but I wanted to understand the design rationale:
A lot of trait-level functionality would be enhanced if a trait could
specify members to be included in the struct which implements the trait.
This can be
Andres (cc'ing rust-dev)-
An initial question, since I'm not clear on one thing:
What is your goal in proposing this change?
That is, is your primary concern that you dislike writing either method
invocations or method definitions? Or are you concerned about the
ability of the compiler to
Would running test-to-destruction cases that are expected to fail count as
running in a sandbox? Currently I spawn them to a separate task and catch
its failure, which is probably better practice - but it would be nice if I
were able to access the message given to fail and compare it with the
Le 20/09/2013 13:40, Henri Sivonen a écrit :
On Tue, Sep 10, 2013 at 6:47 PM, Simon Sapinsimon.sa...@exyr.org wrote:
/// Call this to indicate the end of the input.
/// The Decoder instance should be discarded afterwards.
/// Some encodings may append some final output at this
Le 10/09/2013 16:47, Simon Sapin a écrit :
TR;DR: the actual proposal is at the end of this email.
I moved this to the wiki, to better deal with updates:
https://github.com/mozilla/rust/wiki/Proposal-for-character-encoding-API
--
Simon Sapin
___
Hi Andres,
I'm thinking about your question from a structural typing point of view, so
let me see if an analogy from Scala (which has its own take on traits)
helps. Scala is more of an OO language than Rust is, and Scala traits can
extend classes (abstract or not), which is how it's possible for
Adding struct members in traits would be… weird. Where would those members be
stored when passing things around by value?
This sounds like something for properties. But as Nikko says it is not a
planned feature at the moment – there is enough on the table for 1.0 as it is.
I'm sure they would
On Sep 20, 2013, at 9:48 AM, Alex Crichton a...@crichton.co wrote:
It this not possible to do with tasks?
I don't see how we can catch and rollback any memory modification that a call
into already compiled code might make, not without reimplementing in software
the memory protection that the
How about allowing anonymous fields, like go does? It seems to provide most
of the benefits at very little language complexity cost.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Le vendredi 20 septembre 2013 11:47:04 Simon Sapin a écrit :
Le 20/09/2013 10:18, Olivier Renaud a écrit :
I really like the API you are proposing. In particular, the error handling
is close to what I was expecting from such an API.
I have some remarks, though.
Is there a reason for
Does it HAVE to be a single typed char seen on the English 101 keyboard ?
History Lesson:
The industry in the very early, early days of printing, storing, and
processing characters, both English and non-English, came up with a
solution around the use of Control Characters.
ASCI Char 1 is known
Le vendredi 20 septembre 2013 11:52:14 Simon Sapin a écrit :
Le 13/09/2013 23:03, Simon Sapin a écrit :
/// Takes the invalid byte sequence.
/// Return a replacement string, or None to abort with a DecodeError.
condition! {
pub decoding_error : ~[u8] - Option~str;
}
///
When I mention struct members I'm saying that in order for a struct to
satisfy trait properties (explicitly conforming to the interface, not
implicitly like Go), the struct must have implemented the functions for the
trait and also contain the required members.
Looking at a few more examples, I
Andres Osinski andres.osin...@gmail.com
wrote:
Hi all, I have a question which I'm sure must have already been discussed
and dealt with, but I wanted to understand the design rationale:
A lot of trait-level functionality would be enhanced if a trait could
specify members to be included in
As usual, I'm highly resistant to use of the backtick because Markdown uses
it pervasively. Not only would this make it very annoying to embed Markdown
in strings, it can make it impossible to embed inline Rust code in Markdown
editors. Let's leave the backtick as a metasyntactic symbol.
On Fri,
On Tue, Sep 10, 2013 at 6:47 PM, Simon Sapin simon.sa...@exyr.org wrote:
/// Call this to indicate the end of the input.
/// The Decoder instance should be discarded afterwards.
/// Some encodings may append some final output at this point.
/// May raise the decoding_error
Could it be possible for rusti to spawn a task that runs the expression,
and then if that results in a fail! it would become a simple child-task
failure cleanup, which in this case means printing the appropriate error
message?
Of course, if there is a lot of state, this might not be feasible, but
The current `std::option` API defines 3 versions of most methods, in order
to handle by-value, by-reference and by-mutable-reference. As the module
grows, it will continue to pick up sets of 3 nearly identical methods
rather than one implementation of each.
We could replace the current design
On Fri, Sep 20, 2013 at 4:24 PM, Alex Crichton a...@crichton.co wrote:
Q: Is there a way to *really* just get one thread in the rust runtime?
Best
case, I'm hoping the two threads observed is just a bug that can be
fixed.
Right now the runtime will always spawn at least one thread, so
On 09/19/2013 11:24 AM, Jason E. Aten wrote:
Minh Do and I are looking into how to improve rusti -the- repl, so
that is fast, efficient, and stable. Minh is undertaking this as a
final year project in his CS undergraduate program, and I am mentoring
that project and plan to work on it my spare
On 09/19/2013 11:40 PM, Jason E. Aten wrote:
On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co
mailto:a...@crichton.co wrote:
Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but
I think that it should be important to be able to fail! and have the
AFAIK the go solution walks a thin line here. An anonymous field means one
can directly access any subfield, and also that the container has all the
included struct traits - as implemented by the included struct. It is also
possible to override the implementation.
This is different from what was
In this talk https://www.youtube.com/watch?v=f9Xfh8pv3Fs cling devs say
that they did implement transactions. However the best you could hope for
is to restore internal process state. You can't do much about external
resources such as file handles, sockets, etc, etc, so I wonder if it's even
34 matches
Mail list logo
