On Mon, Apr 14, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.comwrote:
On 14/04/14 12:41 PM, Matthieu Monrocq wrote:
Memory fragmentation is a potential issue in all languages that not use
a Compacting GC, so yes.
It's much less of an issue than people make it out to be on 32-bit, and
On 15/04/14 12:46 PM, Matthieu Monrocq wrote:
By the way, do you have any idea how this is going to pan out on
processors like the Mill CPU where the address space is shared among
processes ?
x86_64 and ARM64 really have a 48-bit address space (cut down to 47-bit
by Linux to separate the
Memory fragmentation is a potential issue in all languages that not use a
Compacting GC, so yes.
There are some attenuating circumstances in Rust, notably the fact that
unless you use a ~ pointer the memory is allocated in a task private heap
which is entirely recycled at the death of the task,
Thanks Matthieu.
I thought that might be the case.
I'll keep a look out as I work with Rust and ping the mailing list if I
need to cross that bridge.
Kind Regards,
Zach
On Mon, Apr 14, 2014 at 12:41 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
Memory fragmentation is a
On 14/04/14 12:41 PM, Matthieu Monrocq wrote:
Memory fragmentation is a potential issue in all languages that not use
a Compacting GC, so yes.
It's much less of an issue than people make it out to be on 32-bit, and
it's a non-issue on 64-bit with a good allocator (jemalloc, tcmalloc).
Small
On 1 December 2013 03:54, Daniel Micay danielmi...@gmail.com wrote:
I don't understand the point of `do` beyond making zero-parameter
closures look a bit better. If it doesn't even do that, why bother? If
an editor isn't indenting it properly, that's an editor issue. As far
as I can tell, the
if do makes the code more readable or more beautiful, I higly recommend
keeping this sugar syntax. If there are corner cases where do doesn't do
the job, the developer should not use it in these cases.
It's still the same debat, when GIMP had this ugly multi panels system,
developers was saying
Not sure what you mean by `self` on `T`. I thought traits can
take self by-value?
On Dec 1, 2013, at 1:22 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 12/1/13 7:42 AM, Vadim wrote:
Once fn()'s should consume their environment, perhaps it should be
simply self, where Self is
I don't want stack once functions, because I feel that their use cases are
better served with RAII, which serves the same purposes without rightward drift
and without forcing LLVM to perform devirtualization.
Patrick
Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for
The main reason for do's existence is to make task spawning look nice. The
closure inference was removed throughout the language because it masked
allocation and doesn't work well with custom smart pointers. If do is still
causing confusion, I'd rather just remove it entirely.
Patrick
Chris
Once stack functions have nothing to do with RAII. It is about container
manipulation methods. Consider the mangle function of a hashmap for
example. It makes perfect sense to be able to access a borrowed pointer and
also consume an owned pointer inside the mangle actions. This is currently
On Sat, 2013-11-30 at 09:34 +0200, Oren Ben-Kiki wrote:
This is a lose-lose situation. If the container takes a `proc`, then
Rust complains that it can't capture the non-send-able variable. But
if the container takes a stack closure, then Rust complains it can't
use the owned variable. Of
That would help a bit, but it would still require the programmer to
manually setup and teardown the tuples, pass them to the closure, and so
on. We'll also need to change each and every function that takes an action
parameter to take the extra tuple in every container or container-like
type. And
If do is still causing confusion, I'd rather just remove it entirely.
I rather like `do`. I agree that if it's confusing it should be considered
for removal, but IMO the confusion here stems from familiarity with the
prior, obsolete semantics rather than any inherent problem with the
construct
On Sat, Nov 30, 2013 at 9:34 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
That would help a bit, but it would still require the programmer to
manually setup and teardown the tuples, pass them to the closure, and so
on. We'll also need to change each and every function that takes an action
On 11/30/13 3:25 AM, Oren Ben-Kiki wrote:
Once stack functions have nothing to do with RAII. It is about container
manipulation methods. Consider the mangle function of a hashmap for
example. It makes perfect sense to be able to access a borrowed pointer
and also consume an owned pointer inside
While we're changing this stuff, I'd like to see lambdas allow return, now
that the need for forbidding that is gone, IIRC. That's more likely to
continually trip me up than unusual allocation mechanisms.
Kevin
On Nov 30, 2013 10:02 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC. That's more likely
to continually trip me up than unusual allocation mechanisms.
No objections here.
Patrick
Should an issue for this be filed then?
--
Ziad
On Sat, Nov 30, 2013 at 10:20 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC.
On Nov 30, 2013, at 10:02 AM, Patrick Walton pcwal...@mozilla.com wrote:
I don't agree in general that the right solution for every problem that can
be solved through the type system is in the type system. Every type system
feature has a cost; when something can be done via what's already
On Nov 30, 2013, at 10:20 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC. That's more likely
to continually trip me up than
Just to mention in passing - there's a related principle that converting a
block to a closure shouldn't change its semantics. This obviously doesn't
fully work because of return/break/continue; that said, if a block without
such flow control constructs is wrapped into a closure, you'd expect it to
(I forget the name, sadly)
This is usually referred to as Tennet's Correspondence Principle:
http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html
...though it is sometimes debated whether or not the modern interpretation
of this principle is actually what Tennet
On 11/30/13 6:34 AM, Oren Ben-Kiki wrote:
That would help a bit, but it would still require the programmer to
manually setup and teardown the tuples, pass them to the closure, and so
on. We'll also need to change each and every function that takes an
action parameter to take the extra tuple in
On 11/30/13 12:04 PM, Oren Ben-Kiki wrote:
Just to mention in passing - there's a related principle that converting
a block to a closure shouldn't change its semantics. This obviously
doesn't fully work because of return/break/continue; that said, if a
block without such flow control constructs
There were several threads about this,
https://mail.mozilla.org/pipermail/rust-dev/2013-October/006105.html for
example. I don't see how that code can be converted to RAII at all. Sure it
can be done with cells, or possibly with tuples (though, well, doing this
_manually_? shudder). It really just
On 11/30/13 1:54 PM, Oren Ben-Kiki wrote:
There were several threads about this,
https://mail.mozilla.org/pipermail/rust-dev/2013-October/006105.html for
example. I don't see how that code can be converted to RAII at all. Sure
it can be done with cells, or possibly with tuples (though, well,
Like I said, this is a boiled-down example of the essence of the problem.
Yes, the hashmap mangle is an example, and the option map, and similar
standard container methods, and quite a few similar functions in my own
specific container classes (contrary to popular opinion, in non-trivial
projects
It's also not clear to me how once fn can decompose into a trait in the
future. The goal in the future is to make fn() a type of trait, to allow for
C++-like zero-indirection closures. The different types of functions that we
have today correspond to different self parameters: |A|-B corresponds
On Fri, Nov 29, 2013 at 11:34 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code.
On Sat, Nov 30, 2013 at 12:26 AM, Patrick Walton pwal...@mozilla.com
wrote:
The main reason for do's existence is to make task spawning look nice.
I've got to say
On Sat, Nov 30, 2013 at 7:55 PM, Tony Arcieri basc...@gmail.com wrote:
On Fri, Nov 29, 2013 at 11:34 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code.
On Sat, Nov 30, 2013 at 12:26 AM, Patrick Walton pwal...@mozilla.com
wrote:
The main reason
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will probably appeal to the people
that Steve Klabnik is drawing to the language with Rust for Rubyists.
It might seem like a small thing but
On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code. Getting rid of it makes a
lot of code look downright ugly. I'd rather it used a more Ruby-ish notation
though, I find that putting the `do` far away from the `{ ... }`
On 11/30/13 7:35 PM, Brendan Zabarauskas wrote:
On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code. Getting rid of
it
makes a lot of code look downright ugly. I'd rather it used a more
Ruby-ish notation though, I find that
On Sat, Nov 30, 2013 at 10:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will probably appeal to the people
that Steve Klabnik is drawing to
On 11/30/13 7:43 PM, Corey Richardson wrote:
Maybe `do` can just change from procs to closures. I can't really say
how often I've actually wanted a proc. Task bodies are a far minority
compared to other uses of do, from the backlash, and I don't find
`spawn(proc() { ... })` that unappealing.
I
On Nov 30, 2013, at 7:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will probably appeal to the people
that Steve Klabnik is drawing to the
On 11/30/13 7:50 PM, Kevin Ballard wrote:
do spawn proc() {
..
}
That's essentially just as verbose as not having do.
And yes, I know do originally existed to make spawning nicer, but
that's not really that ugly, and allows for using `do` with stack
closures (which, in code I've seen,
On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard ke...@sb.org wrote:
On Nov 30, 2013, at 7:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will
On 1 Dec 2013, at 1:45 pm, Patrick Walton pcwal...@mozilla.com wrote:
the experiment of using blocks in place of RAII for stuff like with_c_str
or unkillable has failed: it leads to too much rightward drift.
Patrick
I guess I can agree with that. I remember when I first started with Rust
On Nov 30, 2013, at 7:54 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard ke...@sb.org wrote:
On Nov 30, 2013, at 7:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do
On 11/30/13 8:06 PM, Brendan Zabarauskas wrote:
On 1 Dec 2013, at 1:45 pm, Patrick Walton pcwal...@mozilla.com wrote:
the experiment of using blocks in place of RAII for stuff like with_c_str or
unkillable has failed: it leads to too much rightward drift.
Patrick
I guess I can agree with
I find `do` syntax form is vital for DSL-ish code. Getting rid of it makes
a lot of code look downright ugly. I'd rather it used a more Ruby-ish
notation though, I find that putting the `do` far away from the `{ ... }`
doesn't read well. `foo() do |...| { ... }` would have made more sense
for
Hi!
As I know, As I know, we have SharedChan mechanism which can be used for
many clients - server communications. But how can I send response from
server to many clients? This is not commonly used case, and looks like
there is no such mechanism or I've missed something?
Best regards,
Alexander.
Hi,
I am not quite sure whether you are asking for a multi-cast feature (all
clients receive a copy of the message) or for a send-to-one-among feature
(in which one of the available client would pick up the message).
Could you elaborate ?
-- Matthieu
On Tue, May 28, 2013 at 11:45 AM,
On 05/28/2013 02:45 AM, Alexander Stavonin wrote:
Hi!
As I know, As I know, we have SharedChan mechanism which can be used
for many clients - server communications. But how can I send
response from server to many clients? This is not commonly used case,
and looks like there is no such
Say we want to implement the following function:
fn add(x: Optionint, y: Optionint) - Optionint { ... }
Some functional languages, like Haskell and Scala offer some sort of a do
notation to make unwrapping multiple Option type values easier.
add :: Maybe Int - Maybe Int - Maybe Int
add mx my =
On 2013-05-23, at 14:28 , Benjamin Striegel wrote:
There's no generalized notation, but a while ago I overloaded the +
operator on Option such that it automatically unwraps them, adds the
contained elements together (for any two types that implement Add), and
returns a wrapped result.
On 23/05/13 16:13, Ziad Hatahet wrote:
Say we want to implement the following function:
fn add(x: Optionint, y: Optionint) - Optionint { ... }
Some functional languages, like Haskell and Scala offer some sort of a
do notation to make unwrapping multiple Option type values easier.
add ::
Thanks all for the replies.
Niko, could you point out where in the code you defined the macro you
mention?
Thanks
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I was thinking of the if_ok! macro, which is intended for use with the Result
type:
```
macro_rules! if_ok(
($inp: expr) = (
match $inp {
Ok(v) = { v }
Err(e) = { return Err(e); }
}
)
)
```
It is used like:
```
let foo =
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.
___
Rust-dev mailing list
Rust-dev@mozilla.org
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.
Ah, I see now that nested functions cannot access upvars. I was under
the impression this limitation had been removed. I did not intend to
take away access to upvars (as you and Graydon said, crucial to event
callbacks) but just the anonymous function syntax.
However, I've been thinking it
Hello,
I wanted to do a quick straw poll to ask whether we still need a lambda
expression, given that we have blocks and named functions? Searching
the rust code base, I found that *every* use of lambda was of the form:
|let foo = lambda(...) {...}| which would (in my opinion) be better
55 matches
Mail list logo
