Other programming languages do this. C and C++ do not mandate the use of
RPATH, and Rust not applying RPATH by default doesn't exclude people
opting into it if they want. In this context I am also considering
@executable_path and @loader_path to be 'RPATH', and in fact
@loader_path is the
Brian Anderson bander...@mozilla.com writes:
Hi.
Very soon now the way rustc links crates dynamically is going to
change[1], and it will impact the way you work with Rust in some
important cases. The TL;DR is that rustc will no longer encode RPATH
information in the binaries it produces,
There's a fix for make install waiting on bors right now:
https://github.com/rust-lang/rust/pull/15550
Steven Fackler
On Wed, Jul 9, 2014 at 1:11 PM, Ben Gamari bgamari.f...@gmail.com wrote:
Brian Anderson bander...@mozilla.com writes:
Hi.
Very soon now the way rustc links crates
I ran stats on the type parameters on Rust's master branch.
(I was dumb and only sent this to Ben Striegel last time. My fault for
not knowing how to use an email client.)
On 06/30, Benjamin Striegel wrote:
Whether or not we want something like this, I'd be fascinated if someone
managed to
Hi.
Very soon now the way rustc links crates dynamically is going to
change[1], and it will impact the way you work with Rust in some
important cases. The TL;DR is that rustc will no longer encode RPATH
information in the binaries it produces, so the dynamic linker will be
less likely to
On 08/07/14 23:57, Brian Anderson wrote:
*Running rustc directly from the build directory will no longer work by
default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath
to the configure script.
Does this also apply to running a (nightly) binary distribution from
where the
Yes, it does.
On 07/08/2014 04:41 PM, Simon Sapin wrote:
On 08/07/14 23:57, Brian Anderson wrote:
*Running rustc directly from the build directory will no longer work by
default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath
to the configure script.
Does this also apply to
Yes, I do want something like an nio Selector.
I'm trying to write it myself using epoll and eventfd on Linux. Binding to
the syscall is straightforward. However I can't work out how to get the fds
of IO objects (File struct, for example) so am stuck again.
The ioserver approach sounds promising
在 2014年7月5日，下午11:07，Nat Pryce nat.pr...@gmail.com 写道：
I've been trying to write tasks that wait for both I/O and channel
communication. I've been told that, to maximise communication performance,
channels do not support selecting of both channels and I/O objects.
Therefore a program
A friendly day-of reminder - this meetup is happening TODAY.
We have 8 people marked as attending in Eventbrite - I'm looking forward to
seeing you!
On Tue, Jul 1, 2014 at 1:48 PM, Paul Nathan pnathan.softw...@gmail.com
wrote:
Hello everyone!
It looks like no one has expressed strong
I'm also interesting in some pointers on the best way to achieve this.
--
Daniel Fagnan
@TheHydroImpulse
http://hydrocodedesign.com
M: (780) 983-4997
On Sat, Jul 5, 2014 at 9:07 AM, Nat Pryce nat.pr...@gmail.com wrote:
I've been trying to write tasks that wait for both I/O and channel
Same here, I am highly interested in the topic.
On Jul 5, 2014 10:14 AM, Nat Pryce nat.pr...@gmail.com wrote:
I've been trying to write tasks that wait for both I/O and channel
communication. I've been told that, to maximise communication performance,
channels do not support selecting of both
On Sat, Jul 5, 2014 at 8:07 AM, Nat Pryce nat.pr...@gmail.com wrote:
I've been trying to write tasks that wait for both I/O and channel
communication. I've been told that, to maximise communication performance,
channels do not support selecting of both channels and I/O objects.
Therefore a
I'd like to announce a binding to NanoVG - a small vector-graphics library
written in C that runs on OpenGL backends.
I'm using this project as a way to familiarize with Rust, and so am happy to
learn whatever I can. Comments and suggestions are very welcome.
The project is at
I've been trying to write tasks that wait for both I/O and channel
communication. I've been told that, to maximise communication performance,
channels do not support selecting of both channels and I/O objects.
Therefore a program should signal to a task that is waiting for I/O over
another I/O
Hello!
I was surprised to find the following compile and run without any bother:
#[deriving(Show)]
pub enum MyEnum {
Path
}
fn main() {
let p = Path::new(/filepath/);
let p2 = Path;
println!({},p.as_str());
println!({},p2);
}
% ./run
Some(/filepath)
Path
What is the name
On 7/5/14 1:43 PM, Phil Dawes wrote:
Hello!
I was surprised to find the following compile and run without any bother:
#[deriving(Show)]
pub enum MyEnum {
Path
}
fn main() {
let p = Path::new(/filepath/);
let p2 = Path;
println!({},p.as_str());
println!({},p2);
}
%
Thanks Patrick, that makes sense.
I need to think about how to code this into Racer. Can I assume that
anything preceding a :: in a path is from the type namespace?
(Is there somewhere other than the rustc source where I should be reading
about this?)
Thanks,
Phil
On Sat, Jul 5, 2014 at
On 7/5/14 2:06 PM, Phil Dawes wrote:
Thanks Patrick, that makes sense.
I need to think about how to code this into Racer. Can I assume that
anything preceding a :: in a path is from the type namespace?
Yes.
(Is there somewhere other than the rustc source where I should be
reading about
So at some future point it would be possible to replace
TypedArena_instance().alloc(X) with box(TypedArena_instance) X
avoiding an extra move of X from a temporary allocated on the stack
that the compiler in general cannot optimize?
On 3 July 2014 04:39, Corey Richardson co...@octayn.net wrote:
On 7/2/14 11:08 PM, Igor Bukanov wrote:
So at some future point it would be possible to replace
TypedArena_instance().alloc(X) with box(TypedArena_instance) X
avoiding an extra move of X from a temporary allocated on the stack
that the compiler in general cannot optimize?
Yes. Under the hood,
I've been trying to read up on Rust a little bit, and things look really
amazing. Given the focus on 'safety' and the strong link between safety
and integrity related issues, I was intrigued by the following question:
how far would Rust be removed from possibly becoming an object capability
On 7/2/14 11:09 PM, Rob Meijer wrote:
I've been trying to read up on Rust a little bit, and things look really
amazing. Given the focus on 'safety' and the strong link between safety
and integrity related issues, I was intrigued by the following question:
how far would Rust be removed from
Hi, thanks for your quick replies!
I am thinking that maybe one solution could be that the C code calls
an init function that calls native::start and provides a function pointer
that start calls back into C. That way the C main thread will have a rust
runtime in the background, I *think*?.
I
Perhaps relevant: Cap'n Proto's RPC protocol
http://kentonv.github.io/capnproto/rpc.html aims to be a cross-language
distributed-object-capability system, and I have been working on a Rust
implementation https://github.com/dwrensha/capnproto-rust.
On Thu, Jul 3, 2014 at 2:09 AM, Rob Meijer
The links for FAQ and Manifest Format on http://crates.io should be
rearranged to be at the top of the homepage...instead of the bottom, in my
opinion.
On Wed, Jul 2, 2014 at 7:38 AM, Isak Andersson cont...@bitpuffin.com
wrote:
Hi!
Wow I didn't know about the manifest page, I was under the
I am thinking that maybe one solution could be that the C code calls
an init function that calls native::start and provides a function pointer
that start calls back into C. That way the C main thread will have a rust
runtime in the background, I *think*?.
That is correct!
I hope this would
On Wed, Jul 2, 2014 at 8:56 PM, Brian Anderson bander...@mozilla.com
wrote:
On 07/02/2014 11:19 AM, Gábor Lehel wrote:
Thanks, this is a good step, as is delaying taking actions by a day
as proposed in the meeting itself.
If you have any suggestions for how this regular email or the
On Wed, Jul 2, 2014 at 11:05 PM, Nick Cameron li...@ncameron.org wrote:
On Thu, Jul 3, 2014 at 6:19 AM, Gábor Lehel glaebho...@gmail.com wrote:
Thanks, this is a good step, as is delaying taking actions by a day as
proposed in the meeting itself.
If you have any suggestions for how
Hey Fantix, nice job !
By the way, if you really have time to spare...MQTT would also be a nice
to have library...for the embeddable sensor domain guys.
A bit about it here:
http://clockwerx.blogspot.com/2014/06/whats-mqtt-and-how-can-you-use-it.html
--
-Thad
+ThadGuidry
Aright great! I'll give it a try and let you all know if there is issues.
I'll check the link as well, thank you!
Cheers!
Isak Andersson
On Thu, Jul 3, 2014 at 3:58 PM, Alex Crichton a...@crichton.co wrote:
I am thinking that maybe one solution could be that the C code calls
an init
Here are the recommendations for discussion at next weeks meeting. Last
week we didn't have time to cover older RFCs at the general meeting, so
last weeks RFCs are carried over. Also added is RFC 88 for an update. It
was previously discussed and we decided it hadn't reached a conclusion.
As
Hi,
Here is zmq.rs, a native implementation of ØMQ in the Rust programming
language in MPLv2. I've just got a very ugly prototype running till now,
and I'm expecting to hear more comments on anything.
https://github.com/zeromq/zmq.rs
For who wants to know more about ØMQ, it looks like an
Complaining about something I don't like:
Due to the choice of MPLv2, this won't be usable in the wider Rust
ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a)
requires that any distribution in Executable Form carry a notice
about how to acquire the source code of zmq.rs. This is
Thank you, Corey!
Honestly I didn't dig deep about licensing. It was MIT which I think is the
most open one as BSD. Then http://zeromq.org/docs:organization suggested
MPLv2 - something between BSD and GPL just sounded also not bad for me,
so I didn't pay much attention changing to MPLv2. I
Hello Rust folks!
I am using Cargo and I am trying to specify mulitple targets in my
Cargo.toml file.
First of all is this even possible?
The way I have set things up is that I have src/hmwhoami.rs which builds to
a binary,
and uses src/proof.rs and that builds totally fine.
My Cargo file looks
On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote:
Hello Rust folks!
I am using Cargo and I am trying to specify mulitple targets in my
Cargo.toml file.
First of all is this even possible?
...
[package]
name = hmproof
version = 0.1.0
authors = [ i...@houstonmedia.se ]
[[bin]]
name
Hi!
Thanks for the reply!
Apparently multiple targets does in fact work. Just that you can't rely on
the
default path anymore, so I had to add the path = ... to both the [[lib]]
and [[bin]].
Not sure if this is a bug or not.
However the library compiles as an rlib and I'm not sure how to change
Hi, Isak!
According to manifest documentation [1] you can specify crate type (dynamic or
static lib or rlib) using crate_type option:
[[lib]]
…
crate_type = [dylib, staticlib]
The above configuration should build you both .a and .so files.
[1]: http://crates.io/manifest.html, search for
Hi!
Wow I didn't know about the manifest page, I was under the impression that
the docs were very lacking. But this is pretty great.
Thanks a bunch that was super helpful!
On Wed, Jul 2, 2014 at 2:09 PM, Vladimir Matveev dpx.infin...@gmail.com
wrote:
Hi, Isak!
According to manifest
So far I knew that `ref` could be used in `let` and `match`
expressions. But I just tried using it for a function's parameter to
see what happens and it actually compiled! :)
fn foo(ref p: int) - int {
*p + 1
}
fn main() {
let x = 1729i;
let y = foo(x);
If you do want to do this, you can wrap the type in a struct, as in:
```
use foo_mod::MyTrait;
mod foo_mod {
pub trait MyTrait {
fn foo (self) - int;
}
impl MyTrait for int {
fn foo(self) - int {
return self + 2;
}
}
impl MyTrait for ~str {
fn foo(self) - int {
return 42;
}
}
}
struct
Binding by ref is subtly different that the function still owns the
argument. For example, this may go awry with ref:T
struct Foo;
impl Drop for Foo {
fn drop(mut self) { println!(dropping); }
}
fn foo(ref _param: Foo) {}
fn main() {
let f1: fn(ref:Foo) = foo;
let f2: fn(Foo) = foo;
On Wed, Jul 2, 2014 at 6:21 PM, Alex Crichton wrote:
Binding by ref is subtly different that the function still owns the
argument. For example, this may go awry with ref:T
struct Foo;
impl Drop for Foo {
fn drop(mut self) { println!(dropping); }
}
fn foo(ref _param: Foo) {}
fn
This is awesome! I look forward to deprecating
https://github.com/erickt/rust-zmq.
On Wed, Jul 2, 2014 at 12:40 AM, Fantix King fantix.k...@gmail.com wrote:
Thank you, Corey!
Honestly I didn't dig deep about licensing. It was MIT which I think is
the most open one as BSD. Then
Mozilla and the Rust community are pleased to announce version 0.11.0 of
the Rust compiler and tools. Rust is a systems programming language with a
focus on safety, performance and concurrency.
While this was a very active development cycle, it was largely focused on
polishing the type system and
Thanks, this is a good step, as is delaying taking actions by a day as
proposed in the meeting itself.
If you have any suggestions for how this regular email or the process in
general could be improved, please let us know.
Most fundamentally, what I'm wondering is, why do most of the things
Possibly some of this is driven by how GitHub automatically spams a large
number of people with the conversations. While I'm sure the core team is
more patient than me, I don't want to listen to twenty years worth of
debate about semicolons in a dead RFC. ;D
Kevin
On Wed, Jul 2, 2014 at
On 07/02/2014 11:19 AM, Gábor Lehel wrote:
Thanks, this is a good step, as is delaying taking actions by a day as
proposed in the meeting itself.
If you have any suggestions for how this regular email or the
process in general could be improved, please let us know.
Most
On 07/02/2014 03:16 AM, Corey Richardson wrote:
Complaining about something I don't like:
Due to the choice of MPLv2, this won't be usable in the wider Rust
ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a)
requires that any distribution in Executable Form carry a notice
about
See also the discussion on IRC:
https://botbot.me/mozilla/rust/2014-07-02/?msg=17359232page=22
It wasn't my intention to discourage using any particular license, but
to raise its requirements if they weren't consciously chosen.
On Wed, Jul 2, 2014 at 12:33 PM, SiegeLordEx slab...@aim.com wrote:
On Thu, Jul 3, 2014 at 6:19 AM, Gábor Lehel glaebho...@gmail.com wrote:
Thanks, this is a good step, as is delaying taking actions by a day as
proposed in the meeting itself.
If you have any suggestions for how this regular email or the process in
general could be improved, please let us
I never thought a change like the one I proposed would be accepted. That
was until a few people also supported the idea so it was a shot in the dark.
My motivation for the rfc was the supposed elimination of the ambiguities
that the current syntax has. I mistakenly overlooked the conflict with
Well done! 1.0 draws closer every day. I'm giddy with anticipation.
On Wed, Jul 2, 2014 at 2:07 PM, Alex Crichton a...@crichton.co wrote:
Mozilla and the Rust community are pleased to announce version 0.11.0 of
the Rust compiler and tools. Rust is a systems programming language with a
focus
Congrat and thank for the good work!
On Wed, Jul 2, 2014 at 8:07 PM, Alex Crichton a...@crichton.co wrote:
Mozilla and the Rust community are pleased to announce version 0.11.0
___
Rust-dev mailing list
Rust-dev@mozilla.org
A new number appeared in the version 0.11.0 compared to 0.10. This
looks like a preparation for 0.11.1, ... . Are you starting to support
these releases with bug-eliminations?
___
Rust-dev mailing list
Rust-dev@mozilla.org
Hey all,
I've been working on libcurl bindings for rust. So far, I've only been
focusing on HTTP support. The goal is to provide a fully functioning
HTTP client that robustly handles all the edge cases needed in the
real world. I'm not trying to build the world's most amazing HTTP
client for
And, it seems that I completely forgot to actually provide the link. I
need more coffee!
https://github.com/carllerche/curl-rust
On Wed, Jul 2, 2014 at 3:00 PM, Carl Lerche m...@carllerche.com wrote:
Hey all,
I've been working on libcurl bindings for rust. So far, I've only been
focusing on
Hello!
I have written a library in Rust that has some pub extern fv's in it so
that they are callable from C. I wrote a C program to try calling these
functions and I was met with the following message:
% ./test
You've met with a terrible fate, haven't you?
fatal runtime error: Could not
Are you starting to support these releases with bug-eliminations?
AFAIK there is no intention to start issuing bugfix releases at this time.
The reason for the extra number at the end is for stricter adherence to
Semantic Versioning, which requires a bugfix number.
On Wed, Jul 2, 2014 at 5:50
I think its just so we parse as a proper semantic version. I know I ran
into a problem yesterday where Cargo had to have an extra .0 in my version
number to understand my version declaration.
On Wed, Jul 2, 2014 at 4:50 PM, Zoltán Tóth zo1...@gmail.com wrote:
A new number appeared in the
Hi!
Anything in the std lib that touches the runtime (task spawning and
concurrency stuff, i/o, probably `GcT` and some things I'm forgetting)
will assert that it's being called from within a rust task, meaning it
can obtain a reference to the runtime object providing those services
from it.
As
If you touch runtime services (such as those mentioned by Benjamin),
it is assume that a Rust Task [1] is available. In your case, you're
touching the unwinding service, but you have no set a catch-point for
the call to unwinding anywhere. This sounds like you're triggering a
failure without a
Once in the tutorial, I see this syntax:
let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10];
It seems to me, that should be: boxGc, as it feels like box is referring
to a container type (which the default type is Box_, but may be Rc_ or
Gc_).
What is the principle behind the current notation?
The full syntax is: box [( EXPR )] EXPR
The first expression is the boxer, or where the result of the second
expression will be stored. GC and HEAP are special cased right now as
the only boxers, but the goal is to use a trait such that you can use
Rc, arenas, vectors, or any other arbitrary type
To expand upon what Corey was saying, `box` is basically a huge
special-cased hack right now. I'm surprised that a mention of `box(GC)` is
even included in the tutorial. Someone tell Steve to rip that out. :P
We'll be clarfiying how best to use `box` before 1.0. In the meantime, just
don't use
Imagine a hypothetical database interface:
struct Database { ... }
struct Cursor'a {
db: 'a Database,
...
}
impl Database {
fn query'a('a self, ...) - Cursor'a { ... }
}
Ideally, I would like both the Database, and the Cursor to implement
Drop. The
Drop implementations for types with lifetime parameters need to be tagged
with #[unsafe_destructor] because they're currently unsound in certain
situations: https://github.com/rust-lang/rust/issues/8861. The intended
semantics are what you would expect: Cursor would drop before Database.
It's
Hi,
Can I override trait impl in another module?
For example, I want to do something like this
use foo_mod::MyTrait;
mod foo_mod {
pub trait MyTrait {
fn foo (self) - int;
}
impl MyTrait for int {
fn foo(self) - int {
return self + 2;
}
}
impl MyTrait for ~str {
fn foo(self) - int {
return
Hello everyone!
It looks like no one has expressed strong opinions on the actual date of
the meetup. I have travel next week Wed-Friday, so I pick Monday, June 7th.
:-)
- Eric from UW has offered to give presentations on either the borrow
checker or the runtime. Please let Eric know what you'd
You cannot.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Hi Alex,
The source also supports a number of other platforms such as Android and
iOS now.
Unfortunately iOS build is failing now because of LLVM bug and as
patch for it hasn't yet landed, I believe it shouldn't be mentioned in
release notes.
--
Valerii
signature.asc
Description:
On 06/29/2014 09:30 PM, Nathan Typanski wrote:
I'm wondering if anyone else here has had the thought of supporting
literate programming in Rust. For those who don't know what this is
about, a language with good support for the concept is Haskell [1],
which normally uses bird-style () for code
On Sun, Jun 29, 2014 at 12:48 AM, Benjamin Herr b...@0x539.de wrote:
In parsing a path, if a path segment is immediately followed by an
identifier, start parsing another type right away and use it as the only
element of the type parameter list for the current path segment.
For what it's worth,
Hi all, there have recently been some calls to be more open about the Rust
meetings, in particular to publish the agenda beforehand. The agenda
setting has been quite informal, often not coming together until the
meeting starts. Not to say that we won't publish an agenda in the future,
but that it
I like it.
Lets go all the way down and make `T P` an abbreviation to `TP` and `f x`
an abbreviation to `f(x)`
People will then start to write `f a b` instead of `f(a,b)` since unboxed
closures make this possible. They will also write a macro `defun` to ease
the definitions of such functions and
This is pretty confusing to me because it’s associative in the opposite
direction that function application is associative in functional languages with
automatic currying.
Cameron
On Jun 28, 2014, at 3:48 PM, Benjamin Herr b...@0x539.de wrote:
So, I've been vaguely concerned that types in a
I realize that, but simplifying
ArcExclusiveVecBoxBufferT
into
Arc (Exclusive (Vec (Box (Buffer T
wouldn't really buy us that much.
On Sun, 2014-06-29 at 09:50 -0700, Cameron Zwarich wrote:
This is pretty confusing to me because it’s associative in the opposite
direction that
Isn't:
type my_convonluted_type = ArcExclusiveVecBoxBufferT;
The most common way to avoid retyping long definition? one could also
pretty indent the type definition for readability, since it will be
defined once.
On Sun, Jun 29, 2014 at 9:56 AM, Benjamin Herr b...@0x539.de wrote:
I realize
Literate Rust (.lrs)
I'm wondering if anyone else here has had the thought of supporting
literate programming in Rust. For those who don't know what this is
about, a language with good support for the concept is Haskell [1],
which normally uses bird-style () for code blocks.
I'm not sure if this is exactly what you're looking for, but rust already
has support for running code examples in documentation. If I remember
correctly, all of the code examples in the guide are currently run and
tested as part of make test, so this is at least part way towards what you
want.
It does seem like rustdoc could be extended to do something
approximating literate programming without much hassle. I'd like to see
this project built out-of-tree using the rustdoc and rustc API's.
On 06/29/2014 12:38 PM, Evan G wrote:
I'm not sure if this is exactly what you're looking for,
Thanks to everyone for the excellent feedback. I've submitted an RFC
incorporating many of the ideas from the discussion:
https://github.com/rust-lang/rfcs/pull/146
On Fri, Jun 27, 2014 at 5:58 PM, Patrick Walton pcwal...@mozilla.com
wrote:
On 6/27/14 1:31 AM, Igor Bukanov wrote:
This bug
If the vast majority of types take only a single type parameter, then it
could potentially be worth considering using a unary sigil. (I think D does
something like this.)
Choosing the tilde as the arbitrary symbol here, your example would look
like Arc~Exclusive~Vec~Box~Buffer~T. If you have
Hello Rustilians!
Bors has outdone himself once again in preparing an 0.11.0 release candidate
for us. I've done the usual smoke test, but if you'd also like to try them
out the links are all pasted below. Remember that this is not a signed
release yet, we've only got checksums for these files at
Looks like a bug in libuv to me:
https://github.com/joyent/libuv/blob/a2506c936296006abe7b8a7517c3f37691191858/src/unix/linux-core.c#L49
android-ifaddrs.h depends on sockaddr (defined in sys/socket.h), but never
includes it. linux-core.c does include it, but only after including
So, I've been vaguely concerned that types in a less sigil-heavy Rust
inevitably devolve into what some call spikey lisp, and tried to come
up with some more lightweight syntax. Of course, just removing syntax is
the easiest way to make it weigh less, and it seems like the following
doesn't
Dan,
I thought so too at first, so I tried moving line #include
sys/socket.h before #include android-ifaddrs.h, and still got
the same error. If you take a closer look at the error message, it is
only failing the third time sockaddr is mentioned, so a missing header
couldn't be the reason.
On 27/06/14 01:45 AM, Gregory Maxwell wrote:
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
not going to use checked arithmetic
This bug would be harmless in safe code in Rust as exploiting it
requires array access without bound checking.
On 27 June 2014 07:07, Tony Arcieri basc...@gmail.com wrote:
Thought I'd just throw this one on the fire ;)
On 6/27/14 1:31 AM, Igor Bukanov wrote:
This bug would be harmless in safe code in Rust as exploiting it
requires array access without bound checking.
Correct. This is a prime example of what I was talking about in my
earlier message: weaponizing integer overflows is much more difficult in
a
Hey all,
So! The new tutorial will be focused on building several small
projects in Rust. This example is the first one: a classic 'guessing
game.' This was one of the first programs I wrote when I first learned
C.
I'd like the feedback of the community before I actually start writing
the guide.
Thought I'd just throw this one on the fire ;)
http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 27/06/14 01:07 AM, Tony Arcieri wrote:
Thought I'd just throw this one on the fire ;)
http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com
wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
not going to use checked arithmetic types. Every branch that the
programmer
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
not going to use checked arithmetic types. Every branch that the
programmer
On 27/06/14 01:38 AM, Tony Arcieri wrote:
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
Hi Jussi,
Thanks. meson looks like CMake with a somewhat more sane build config
language. Not directly related to Rust, but what is the tooling story
like with Qt Creator - eg. has any work been done on teaching Qt
Creator to understand meson projects?
On 23 June 2014 21:00, Jussi Pakkanen
I wasn't thinking of subtyping u32w to u32. I actually don't think that
u32 should be convertible to u32w (or vice-versa) without an explicit
cast. For array slices, it would have to be a transmute-like function,
e.g. fn as_wrapping'a(s:'a [u32])-'a [u32w] { unsafe { transmute(s) } }
On 26.06.2014 00:04, Vadim Chugunov wrote:
I wasn't thinking of subtyping u32w to u32. I actually don't think that
u32 should be convertible to u32w (or vice-versa) without an explicit
cast. For array slices, it would have to be a transmute-like function,
e.g. fn as_wrapping'a(s:'a
801 - 900 of 8896 matches
Mail list logo
