Is it possible to include into the one crate as Rust as C code?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I have a C function with void* argument wich will be passed to callback and
I want to pass Rust record as the argument. The question is, how to
allocate record on memory but not on the stack? I've tried a lot of
different ways, but with same result: in callback function record data
looked as
On 12-04-16 06:01 AM, Alexander Stavonin wrote:
Is it possible to include into the one crate as Rust as C code?
Rust can call C by declaring the C functions within a suitably named
rust native module. C can call rust only by rust passing C a pointer to
a 'crust' function.
Currently the rust
On 04/16/2012 06:01 AM, Alexander Stavonin wrote:
Is it possible to include into the one crate as Rust as C code?
Yes it is possible. There's no explicit support for it but native
modules may refer to static libraries and it's relatively easy to link
arbitrary static libraries into a crate.
On 12-04-15 06:23 PM, Joe Groff wrote:
On Sun, Apr 15, 2012 at 6:19 PM, Patrick Walton pwal...@mozilla.com wrote:
Only if LLVM's optimizer is smart enough to turn that code into a goto-based
state machine. I'm not sure if it is. (Of course, if it's not, that's
possibly fixable...)
IIRC
On 4/16/12 11:46 AM, Graydon Hoare wrote:
They're already present (were from the beginning) but they broke when
we shifted from rustboot (hand-rolled code generator) to rustc (LLVM).
It turns out that you have to adopt a somewhat pessimistic ABI in all
cases if your functions are to be
On 12-04-16 11:49 AM, Patrick Walton wrote:
On 4/16/12 11:46 AM, Graydon Hoare wrote:
They're already present (were from the beginning) but they broke when
we shifted from rustboot (hand-rolled code generator) to rustc (LLVM).
It turns out that you have to adopt a somewhat pessimistic ABI in
On 12-04-13 11:07 PM, Kobi Lurie wrote:
one is reverse application.
it's actually logical and might simplify things.
(similar to extension methods in c#)
there are no classes, but a syntax like: obj.method(b,c) still exists.
from what I could tell, the function is really method(obj,b,c), and
Hey.
Using bindings has been complicated by our lack of configuration for
locating native libraries. Until now we've had to hack in `link_args`
attributes in order to specify where native libraries live. Today I
checked in a change that makes the `-L` flag also apply to native
libraries, so
On Mon, Apr 16, 2012 at 3:22 PM, Graydon Hoare gray...@mozilla.com wrote:
- Our records are order-sensitive, to be C-structure compatible.
Keyword arguments are usually argued-for (as you are doing here) as
a way to make function arguments order-insensitive. We'd need to
decide whether
Hi,
Am Montag, 16. April 2012 um 20:54 schrieb Graydon Hoare:
On 12-04-16 11:49 AM, Patrick Walton wrote:
On 4/16/12 11:46 AM, Graydon Hoare wrote:
They're already present (were from the beginning) but they broke when
we shifted from rustboot (hand-rolled code generator) to rustc
On 12-04-16 04:07 PM, Stefan Plantikow wrote:
Some algorithms just yearn for being written in a recursive style.
Or state-machine style, yeah. IMO the use case for tail calls is more
state machines than recursion. But both can be rewritten without. I
think it's just a style issue; I don't
I think that if we want to support something like the `self` type, we need to
go all out and truly support higher-kinded types. The current system is too
weak to really express anything useful. I mean, you can write useful ifaces,
but you can't work with them in a generic fashion. For
Hi,
Am Donnerstag, 12. April 2012 um 15:47 schrieb Niko Matsakis:
Not only that, but it adds an extra layer of complexity for type
inferencing, which quite frankly is already complex enough.
That said, you can do a limited form of overloading using impls:
impl methods for int {
fn
On 4/16/12 5:58 PM, Stefan Plantikow wrote:
I think it would be nice too have some syntax support for building ifaces like
that, perhaps via macros.
I can see this approach being useful in cases of multiple inputs. In
any case, it reminds me of this bug:
Motivated by the thread paring back the self type to be, well, just a
type https://mail.mozilla.org/pipermail/rust-dev/2012-April/001661.html
I decided to see how far I could get toward implementing monads given the
self type [constructor] as-is. I ran into several things that got in the
way, so
On 4/16/12 6:23 PM, Steven Blenkinsop wrote:
Motivated by the thread paring back the self type to be, well, just a
type
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001661.html I
decided to see how far I could get toward implementing monads given
the self type [constructor] as-is. I
17 matches
Mail list logo
