On 27/12/14 11:48 AM, Clark Gaebel wrote:
The abi is allowed to change post 1.0. If it wasn't, we'd be stuck with
cdecl forever and that sucks.
I've only seen fastcall used for intracrate leaf calls.
Servo and rustc are the two biggest rust projects.
The mailing list is mostly dead BTW.
On 10/12/14 01:08 PM, Matt wrote:
Sorry if this has been covered before, and also that I'm a complete noob, but
I'm thinking about trying a first project in Rust, and trying to learn enough
to get started.
My plan is for an on-disk key-value store. I'm going to end up writing arrays
of
On 09/12/14 10:43 PM, C K Kashyap wrote:
Hi,
Looks like on my ubuntu 64 bit, when I compile
hello(ABCD);
I get
719e: 48 8d 05 e0 68 04 00lea0x468e0(%rip),%rax
# 4da85 str1405
71a5: 48 89 44 24 08 mov%rax,0x8(%rsp)
71aa:
On 26/11/14 12:26 PM, grayfox wrote:
Hey guys,
I'm really new to Rust (actually I've looked on Rust the last 5 hours the
first time) but I think I produced something that shouldn't be possible. From
the pointer guide I know that the following code will not compile because in
the end I
On 15/11/14 05:24 PM, Paul Colomiets wrote:
Hi Brian,
On Sat, Nov 15, 2014 at 11:23 PM, Brian Anderson bander...@mozilla.com
wrote:
I believe it is not possible to link to glibc statically. My understanding
is that to get a Rust binary that does not depend on a system-provided libc
at all
On 12/10/14 03:16 PM, Nick Cameron wrote:
On a different note, I would be really keen to see dynamic or static
analysis of unsafe blocks to show that they do in fact re-establish the
invariants that the rust compiler expects by the end of the unsafe
block. I expect this is hard to do, but
On 30/09/14 01:44 AM, Tony Arcieri wrote:
Sidebar on SBuf: I'd be curious how it could be written completely in
terms of MemoryMap, or if MemoryMap needs to be extended to support
mprotect() / VirtualProtect().
MemoryMap doesn't support controlling memory protections.
signature.asc
On 25/09/14 03:17 PM, Fredrik Widlund wrote:
http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/
(disclaimer: *not* about comparing languages and claiming language X is
better than language Y)
Kind regards,
Fredrik Widlund
On 22/09/14 03:21 PM, Chris Morgan wrote:
It's completely unnecessary actually.
Would that it were. There was a time when I believed it was, but it's not.
If a method requires a XSS-safe string, then it should take the
XssSafeString parameter, which would implement DerefString and would
be
On 22/09/14 05:12 PM, Tony Arcieri wrote:
On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It
uses `unsafe` as a memory safety boundary, and in this case
On 22/09/14 06:45 PM, Manish Goregaokar wrote:
As Chris mentioned, it's not about using the type system to create
safety. We're assuming that exists, the idea is to gate unchecked access
to the data (which /is/ required for libraries created for generic use)
with the `unsafe` keyword. However,
On 21/09/14 02:29 AM, Tony Arcieri wrote:
Traditionally in Rust, unsafe has centered around memory safety. The
reference manual describes it as such:
http://doc.rust-lang.org/rust.html#unsafety
At Strange Loop, during Chris Morgan's talk, someone asked about using
the type system to
On 21/09/14 05:57 AM, Simon Sapin wrote:
On 21/09/14 07:34, Daniel Micay wrote:
It's not intended to be used for anything other than memory safety.
It’s also used to maintain invariants, such as the bytes inside a String
being valid UTF-8: String::push_bytes() is unsafe, but
String
On 21/09/14 04:27 PM, Evan G wrote:
Personally, I feel safety generalizes pretty well to any concept
that should be called out explicitly as unsafe--not just memory
safety.
That's not how Rust defines `unsafe`. It's open to misuse, and the
compiler will happily point out that it's not being
On 19/09/14 12:40 PM, Matthieu Monrocq wrote:
On Fri, Sep 19, 2014 at 6:13 AM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 19/09/14 12:09 AM, Lee Wei Yen wrote:
Hi all!
I’ve just started learning to use Rust now, and so far it’s been
On 19/09/14 12:46 PM, Jauhien Piatlicki wrote:
Hi,
On 09/19/2014 06:40 PM, Matthieu Monrocq wrote:
Disclaimer, for the unwary, GMP is a GPL library; so using it implies
complying with the GPL license.
LGPL afaik, so you can dynamically link with it in any case.
Static linking of a
On 19/09/14 12:09 AM, Lee Wei Yen wrote:
Hi all!
I’ve just started learning to use Rust now, and so far it’s been
everything I wanted in a language.
I saw from the docs that the num::bigint::BigInt type has been
deprecated - does it have a replacement?
--
Lee Wei Yen
It was moved
On 01/09/14 08:51 AM, Cody Mack wrote:
Hi,
Regarding issue #8937 (https://github.com/rust-lang/rust/issues/8937),
add a BigDecimal type, there is discussion about wrapping GMP, and
even possibly replacing Rust's current BigInt with this wrapper. One
comment mentions that Rust's current
On 19/08/14 04:39 PM, Evan G wrote:
Is there a way to capture some variables by-value, and others
by-reference? The 'ref' syntax you talked about seemed to be only for
the whole argument list, but I might have misunderstood.
You can capture references by-value, because they're normal values.
On 26/07/14 12:56 PM, Patrick Walton wrote:
On 7/26/14 5:54 AM, SiegeLordEx wrote:
While this doesn't matter for the pow function (the alternate function
would just have a different path/name), it matters for the special
syntaxes. When the Iterator is no longer enough for you (there was a
On 24/07/14 11:59 AM, Lionel Parreaux wrote:
I can't pronounce myself about the suitability of features in the Rust
language, but it may be worth noting that some convenient high-level
features are already present in the language, like garbage collection.
There isn't an implementation of
On 14/07/14 02:45 PM, Christoph Husse wrote:
Now I can hear the screams already :D. So I want to explain a bit
about this choice.
First, I find the rust source code I looked at so far pretty
unstructured and confusing. Everything seems to be defined somewhere
at will, without having a
On 14/07/14 03:33 PM, Robin Kruppe wrote:
Second, the signature of MyClass::new() in your example is... unusual.
The return type unnecessarily narrow (returns a trait object instead of
the concrete type, even though callers have to know the concrete type
anyway to call new()) and does a
On 11/07/14 03:15 PM, Alex Crichton wrote:
LD_LIBRARY_PATH is not known about by many
The install.sh script now recommends adding an entry to this variable
if it detects that this is necessary, so it's not *entirely* unknown.
This doesn't help, however, if it's considered a bad practice.
On 10/07/14 03:46 AM, Gioele Barabucci wrote:
Hi,
the current robots.txt on docs.rust-lang.org prevents Archive.org from
storing copies of the old documentation. I think having the old
documentation archived would be a good thing. BTW, all the documentation
before 0.10 seems gone and this
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
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 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
On 24/06/14 01:55 AM, Jerry Morrison wrote:
On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 24/06/14 01:17 AM, Jerry Morrison wrote:
Does `checked { }` mean all functions within that scope use
checked
On 24/06/14 10:57 AM, Lars Bergstrom wrote:
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a
On 24/06/14 11:12 AM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply
On 24/06/14 02:51 PM, Gregory Maxwell wrote:
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here
On 24/06/14 02:34 PM, Daniel Micay wrote:
You haven't explained how this is going to cause security issues in
Rust, when the language is guaranteed to be memory safe outside of
`unsafe` blocks. The `unsafe` blocks are low-level, performance critical
code where unnecessary overflow checks
On 24/06/14 03:06 PM, Erick Tryzelaar wrote:
I've been (very slowly) working on a pure rust build system
(https://github.com/erickt/rbuild) that we might be able to someday use
to do complex builds without needing other external language or build
system.
Well, +1 for that because it's very
On 24/06/14 03:33 PM, Thad Guidry wrote:
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning
the goals of Rust. The team has not deviated from their objective of the
Rust model. Kudos.)
Well, I don't speak for
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
On 22/06/14 12:16 PM, SiegeLord wrote:
On 06/22/2014 11:32 AM, Benjamin Striegel wrote:
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge cases are the norm, not the
exception, and where 80/20 does not apply.
Even in systems
On 23/06/14 04:10 PM, Tony Arcieri wrote:
On Monday, June 23, 2014, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust is not a language designed for an imaginary sufficiently smart
compiler. It targets real architectures and the real LLVM backend.
I
On 23/06/14 04:01 PM, John Regehr wrote:
I doubt it, since Swift has a high level IR above LLVM IR and the
implementation isn't open-source. The language-specific optimizations
like removing overflow / bounds checks based on type system rules will
almost certainly be done on the high-level SIL
On 23/06/14 04:00 PM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay danielmi...@gmail.com wrote:
The discussion here is about checking for both signed / unsigned integer
overflow, as in passing both `-fsanitize=signed-integer-overflow` and
`-fsanitize=unsigned-integer
On 23/06/14 03:59 PM, Cameron Zwarich wrote:
On Jun 22, 2014, at 4:12 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/22/14 2:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too
On 23/06/14 04:58 PM, Patrick Walton wrote:
On 6/23/14 1:55 PM, Daniel Micay wrote:
It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.
I agree with your general concerns, but I should nitpick
On 23/06/14 05:11 PM, Gregory Maxwell wrote:
Calling things 'slower than java' is a little bit hyperbole with the
actual numbers posted here. But I agree any non-trivial slowdown by
default would adversely impact adoption, I don't consider that
desirable.
It's really not hyperbole. Java's
On 23/06/14 05:08 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
It would be an enormous mistake to ship a language with region typing /
move semantics and worse before than Java.
You keep saying
On 23/06/14 05:38 PM, Benjamin Striegel wrote:
I feel like Rust might be missing out on the free lunch I expect Swift
to provide
I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest
benefactor of LLVM, which powers
On 23/06/14 05:57 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust is a performance-centric systems language, Swift is not.
You say that, but I don't see how it applies to my argument. 2 of the 3
On 23/06/14 06:08 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
The language shouldn't be designed around the hypothetical good will of
a corporation. Anyway, I don't know why Swift would have the high
On 23/06/14 06:34 PM, comex wrote:
On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
I'd like to also note that Apple has no external incentive to improve Swift.
Objective-C was a dead language before Apple's fiat rocketed it into the
position of world's
On 23/06/14 08:16 PM, John Regehr wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at a higher scope.
I'm just
On 23/06/14 11:58 PM, François-Xavier Bourlet wrote:
In short:
- everybody wants checked integer arithmetic because it helps to
write better code (thanks to compile time and runtime errors)
- nobody wants to pay the price in performances, but maybe in the
future, hardware++ will make it
On 24/06/14 01:22 AM, comex wrote:
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens there should also be a module-level
attribute
On 24/06/14 01:34 AM, Daniel Micay wrote:
On 24/06/14 01:22 AM, comex wrote:
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect, that's icing on the cake.
It's never going to be free or even cheap. Replacing
On 22/06/14 11:39 AM, Evan G wrote:
Because of memory safety?
Most modern languages are memory safe. They're also significantly easier
to use than Rust, because the compiler / runtime is responsible for
managing object lifetimes.
Because you want low-level control without absolute speed?
I'm
On 22/06/14 11:32 AM, Benjamin Striegel wrote:
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust
code should not require absolute speed
This is a mistaken assumption. Systems programming exists on the
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes, but the default
behavior is no check? IMO this would be the best of
On 22/06/14 05:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too much of a
performance sacrifice. What do we say to those people? Is it just that
memory safety is important because of
On 22/06/14 05:48 PM, Masklinn wrote:
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow
On 22/06/14 06:37 AM, Matthieu Monrocq wrote:
I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right
whenever going from one mode to the other is
On 22/06/14 07:43 PM, Vadim Chugunov wrote:
Makes sense, but I am curious, how do you see adding this post-1.0?
Would you:
- add overflow-checked int types and tell everybody to use them instead
of the default ones from that point on
- declare that in Rust2 integers are overflow-checked,
On 22/06/14 07:26 PM, Gábor Lehel wrote:
Coincidentally, I didn't propose it. I proposed one implementation with
owned allocation (which we already have) in the `prelude` and one with
tracing GC allocation in the `gc` module.
Then I don't understand why we would have one for task-local
On 22/06/14 08:25 PM, Jerry Morrison wrote:
The post also links to Wikipedia on Intel MPX
http://en.wikipedia.org/wiki/Intel_MPX: Intel is adding x86 extensions
to aid memory safety! I think it's for array bounds checking, but the
article is unclear.
It's for faster (but not free) array
On 22/06/14 07:24 PM, Andrew Poelstra wrote:
On Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote:
Rust's design is based on the assumption that performance cannot be
achieved simply by having highly optimized inner loops. It takes a whole
program approach to performance by exposing
On 22/06/14 11:52 PM, Patrick Walton wrote:
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
On 22/06/14 06:43 PM, Clark Gaebel wrote:
I think a reasonable middle ground is to have checked operators that
look a little funny. Kind of like swift, but in reverse:
malloc((number_of_elements +~ 12) *~ size_of::int())
Where adding a ~ to the end of an operator makes it check for
On 23/06/14 12:17 AM, comex wrote:
On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
Anyway, no one has offered an explanation of how they're
planning on integrating this into LLVM and how they propose turning a
trapping operation into unwinding across various
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
On 23/06/14 12:46 AM, comex wrote:
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing
On 23/06/14 01:15 AM, comex wrote:
On Mon, Jun 23, 2014 at 1:05 AM, Daniel Micay danielmi...@gmail.com wrote:
The call we make to perform unwinding isn't a pure function though, it's
aware of the context causing it to unwind. As long as we're supporting
stuff like backtraces outside
On 23/06/14 01:16 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 10:00 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com
On 21/06/14 02:06 AM, Nick Cameron wrote:
bstrie: you're right it is a trade off, but I don't agree that its not
worth it. We're talking about non-atomic incrementing of an integer -
that is pretty much the cheapest thing you can do on a processor (not
free of course, since caching, etc., but
On 21/06/14 05:21 PM, Vadim Chugunov wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a
only matter of time before architectures that implement zero-cost
integer overflow checking appear. I think we should be ready for it
when this happens. So I would
On 21/06/14 05:47 PM, Tony Arcieri wrote:
On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
ARM and x86_64 aren't going anywhere and it's too late for trap on
overflow to be part of the baseline instruction set. It's far from
On 21/06/14 06:54 PM, Jerry Morrison wrote:
I agree with Vadim that the world will inevitably become
security-conscious -- also safety-conscious. We will live to see it
unless such a bug causes nuclear war or power grid meltdown.
When the sea change happens, Rust will either be (A)/ the
On 21/06/14 06:26 PM, comex wrote:
On Sat, Jun 21, 2014 at 6:02 PM, Daniel Micay danielmi...@gmail.com wrote:
It's not possible to add new instructions to x86_64 that are not large
and hard to decode. It's too late, nothing short of breaking backwards
compatibility by introducing a new
On 21/06/14 07:27 PM, Jerry Morrison wrote:
On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 21/06/14 06:54 PM, Jerry Morrison wrote:
I agree with Vadim that the world will inevitably become
security-conscious -- also
On 21/06/14 07:55 PM, Benjamin Striegel wrote:
No one will use Rust if it's slow. If it uses checked arithmetic, it
will be slow. There's nothing subjective about that.
This is the only argument that matters.
If we are slower than C++, Rust will not replace C++ and will have
failed at its
On 21/06/14 08:16 PM, Tony Arcieri wrote:
On Sat, Jun 21, 2014 at 4:55 PM, Benjamin Striegel
ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote:
In addition, bringing up hypothetical CPU architectures with support
for checked arithmetic is not relevant. Rust is a language
On 20/06/14 07:36 AM, Nathan Typanski wrote:
On 06/19, Benjamin Striegel wrote:
I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
On 20/06/14 02:02 PM, Josh Haberman wrote:
Does Rust have any way of optimizing away repeated calls to the same
function where possible? Like GCC's pure function attribute?
To get a little more crazy, say you're working with a Map. Sometimes
it's convenient to write code like this:
if
On 19/06/14 03:05 AM, Jerry Morrison wrote:
BigUint is weird: It can underflow but not overflow. When you use its
value in a more bounded way you'll need to bounds-check it then, whether
it can go negative or not. Wouldn't it be easier to discard it than
squeeze it into the wraparound or
On 18/06/14 03:40 PM, comex wrote:
On Wed, Jun 18, 2014 at 1:08 PM, Gábor Lehel glaebho...@gmail.com wrote:
To partially address this, once we have tracing GC, and if we manage to make
`GcT: Copy`, we should add unbounded `Integer` (as in Haskell) and
`Natural` types which internally use `Gc`,
On 11/06/14 01:54 PM, Tommi wrote:
If the `Mul` trait and similar were changed to take `self` by value, perhaps
the following kind of language design would make more sense:
If a variable of a type that has a destructor is passed to a function by
value (moved), and the variable is used
On 05/06/14 02:27 AM, Paul Nathan wrote:
This won't work in a CSP system. So
Rust isn't a pure CSP system. It has both immutable and mutable shared
memory alongside various forms of channels. The best tool for the job
will vary based on the specific use case. Channels will often be the
On 03/06/14 05:58 AM, Sebastian Gesemann wrote:
On Mon, Jun 2, 2014 at 10:09 PM, Matthew McPherrin wrote:
On Mon, Jun 2, 2014 at 8:25 AM, Patrick Walton wrote:
On 6/2/14 12:44 AM, Tommi wrote:
In my original post I stated that it feels like there's something wrong
with the language when it
On 01/06/14 04:34 AM, Christophe Pedretti wrote:
Hello all,
I've read this :
http://words.steveklabnik.com/pointers-in-rust-a-guide
I am coming from Java where everything is passed and returned by
reference (except for primitive data types), no choice.
I know that with C, you have to
On 29/05/14 05:22 PM, Oleg Eterevsky wrote:
What would be Rust alternative, except passing the errors all around
parser? Doesn't it grow parser code by at least 50%?
Haskell has no exception, it has Monads instead. Rust reuses Option and
Result (Maybe and Either in Haskell) with great
On 29/05/14 08:52 PM, Tommi wrote:
On 2014-05-30, at 3:42, Eric Reed ecr...@cs.washington.edu wrote:
Rust *does* have function overloading. That's *exactly* what traits are for.
If you want to overload a function, then make it a trait and impl the trait
for all the types you want to
On 29/05/14 09:05 PM, Oleg Eterevsky wrote:
If a type implements both Iterator and RandomAccessIterator, wouldn't
it lead to a conflict?
No, it won't. There's a default implementation for types implementing
the Iterator trait, and only a single explicit implementation.
There are other more
On 29/05/14 09:46 PM, Daniel Micay wrote:
On 29/05/14 09:05 PM, Oleg Eterevsky wrote:
If a type implements both Iterator and RandomAccessIterator, wouldn't
it lead to a conflict?
No, it won't. There's a default implementation for types implementing
the Iterator trait, and only a single
On 28/05/14 10:07 AM, Benjamin Striegel wrote:
I think that the naming of `len` here is dangerously misleading. Naive
ASCII-users will be free to assume that this is counting codepoints
rather than bytes. I'd prefer the name `byte_len` in order to make the
behavior here explicit.
It doesn't
On 21/05/14 09:19 AM, Zoltán Tóth wrote:
Daniel Micay danielmi...@gmail.com mailto:danielmi...@gmail.com wrote:
... the default
allocator, which is jemalloc right now.
Rust's memory management is still under-documented in the manual. I have
a question which have been bothering
On 20/05/14 06:45 PM, Masanori Ogino wrote:
Hello.
I found that the Reference Manual uses the term owning pointer, the
Pointer Guide and liballoc do owned pointer and Tutorial does owned box.
Which term is canonical today?
--
Masanori Ogino masanori.og...@gmail.com
On 20/05/14 07:41 PM, Liigo Zhuang wrote:
Could you show us the memory layout of BoxT? Thank you!
The memory layout is just a pointer to a dynamic allocation with the
size of the value. Providing the dynamic allocation is up to the default
allocator, which is jemalloc right now.
signature.asc
On 16/05/14 12:10 AM, Tommi wrote:
I was just wondering, why do we have to explicitly specify the lifetimes of
references returned from functions? Couldn't the compiler figure those
lifetimes out by itself by analyzing the code in the function?
Type inference is local to functions, so it
On 16/05/14 12:14 AM, Daniel Micay wrote:
On 16/05/14 12:10 AM, Tommi wrote:
I was just wondering, why do we have to explicitly specify the lifetimes of
references returned from functions? Couldn't the compiler figure those
lifetimes out by itself by analyzing the code in the function
You can convert ~str to str with `as_slice`. It will also coerce, but
that will likely go away in the near future.
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 05/05/14 03:36 AM, Urban Hafner wrote:
Hey all,
a question from a Rust newbie here. From languages like C or C++ I'm
used to being able to compile each file separately into object files to
speed up the compilation process. In Rust that doesn't seem to be easily
possible. I tried to
On 05/05/14 02:42 PM, John Mija wrote:
I like the project clearcrypt and it is awesome that developers start to
build different algorithms than standard ones.
But it's also necessary to have the most used algorithms, like i.e.:
aes
rsa
des
hmac
md5
rsa
sha1, sha256, sha512
None of
1 - 100 of 434 matches
Mail list logo
