On 4/23/14 7:09 PM, Niko Matsakis wrote:
If we just made y a pointer to x, we'd be in trouble.
Well, not if the mutation to x is also done by making it a pointer to
the scratch space occupied by `something_else()`.
Patrick
___
Rust-dev mailing
Vladimir Pouzanov farcal...@gmail.com writes:
There is a number of options on the memory side of things. I feel that
stack usage could be estimated a bit more simply with rust and it's
__morestack support, so that it would be possible to run a few threads with
preemptive scheduling
On Thu, Apr 24, 2014 at 9:01 AM, Ben Gamari bgam...@gmail.com wrote:
Unfortunately this replaces the ugly possibility of unpredictable
crashes with the slightly less ugly possiblity of unpredictable
deadlocks if we run out of stack in the middle of execution. Perhaps
threads could be
Hi everyone,
I've been learning Rust for the last couple of weeks and I'm quite excited
with it. My experience is mainly in C and Rust feels like a nice
improvement. Thank you for the hard work!
I've recently found this bit of the tutorial:
Vladimir Pouzanov farcal...@gmail.com writes:
On Thu, Apr 24, 2014 at 9:01 AM, Ben Gamari bgam...@gmail.com wrote:
Unfortunately this replaces the ugly possibility of unpredictable
crashes with the slightly less ugly possiblity of unpredictable
deadlocks if we run out of stack in the middle
The documentation for the FFI seems focused on using C code in a
program whose main() is in Rust. Can Rust be used for implementing a
shared library that implements a C ABI for use by programs whose
main() is not in Rust (i.e. the caller sees a C ABI and doesn't know
about Rust)? If yes, can a C
On 24 Apr 2014, at 13:16, Henri Sivonen wrote:
The documentation for the FFI seems focused on using C code in a
program whose main() is in Rust. Can Rust be used for implementing a
shared library that implements a C ABI for use by programs whose
main() is not in Rust (i.e. the caller sees a C
2014-04-24 13:20 GMT+02:00 Stéphane Wirtel steph...@wirtel.be:
On 24 Apr 2014, at 13:16, Henri Sivonen wrote:
The documentation for the FFI seems focused on using C code in a
program whose main() is in Rust. Can Rust be used for implementing a
shared library that implements a C ABI for use
https://github.com/Jurily/rust-c-example
`#[no_mangle] extern C foo() { ... }`
When you expose a C API, you need to observe the C rules: function names
must be globally unique. You have to write the headers yourself. Taking and
releasing ownership of C data needs some magic, but it's doable.
I think that on windows because of name manglings in __cdecl it is not
possible? Or it is?
Mahmut Bulut
On 24 Apr 2014, at 14:16, Henri Sivonen hsivo...@hsivonen.fi wrote:
The documentation for the FFI seems focused on using C code in a
program whose main() is in Rust. Can Rust be
http://static.rust-lang.org/doc/master/guide-ffi.html#foreign-calling-conventions
I forgot about `extern system`, sorry :)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Nice, but why isn't the LLVM optimizer removing the move?
Is it lack of proper alias analysis?
Sounds like that is a separate issue worth pursuing.
The remaining, more difficult, issue is initialization of
aggregate data structures via constructor functions, which still
involves a bunch of
On 4/24/14 8:16 AM, Bill Myers wrote:
Nice, but why isn't the LLVM optimizer removing the move?
Is it lack of proper alias analysis?
Sounds like that is a separate issue worth pursuing.
LLVM's MemCpyOptimizer is pretty badly ordered in the pipeline and needs
to be rewritten.
In any case, I
Bonus: BoxT, OwnT, HeapT would play nicer with allocators (in terms
of syntax) than ~T.
On Thu, Apr 24, 2014 at 11:52 AM, Bill Myers bill_my...@outlook.com wrote:
Something like this will work, yes. It'll probably look more like:
Box::new(*x)
This will be described in some of the
Something like this will work, yes. It'll probably look more like:
Box::new(*x)
This will be described in some of the RFCs that are coming up soon.
Awesome!
We should really get rid of the ~T syntax in favor of FooT (where Foo = Box,
Own, Heap, etc.), since it is deceptively simple
Hello,
I have a problem in my code and I can't find a solution. I develop a
test case that generate the same error. Any idea?
use std::vec::Vec;
use std::rc::Rc;
use std::cell::RefCell;
struct Test;
impl Test {
fn match_fn'a('a self) -Option'a Test {
None
}
fn
Hi, the following modified program seems to work (I am using rustc
0.11-pre-nightly (d35804e 2014-04-18 00:01:22 -0700) :
**
use std::vec::Vec;
use std::rc::Rc;
use std::cell::RefCell;
struct Test;
impl Test {
fn match_fn'a('a self)
Ben Gamari bgam...@gmail.com writes:
Vladimir Pouzanov farcal...@gmail.com writes:
...
My current idea is to make dedicated pools that could hold a compile-time
configurable number of objects of same size, e.g. an IncomingPacketPool
that can hold up to 3 frames where one frame is 128 bytes
18 matches
Mail list logo
