On 28/03/14 03:48, Daniel Micay wrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity.
Actually, I believe
On 28/03/14 15:31, Sanghyeon Seo wrote:
To defend rustc's honor: rustc has no such design issues.
That's my favourite part of this whole thread. Really. :D
--
Lee
___
Rust-dev mailing list
Rust-dev@mozilla.org
I think the point is that the compiler should not be forcing people to
do things, but enabling people to do things, with sensible defaults.
Personally, whilst I would advocate MORE bounds checking in rust for
debugging / prototyping purposes, I don't think bounds checking is even
ideal. It's
process would do.
On 27/03/14 23:16, Corey Richardson wrote:
It's not about debugging, it's about memory safety. It'd be ridiculous
to disable bounds checking just because you've done QA. How many
security exploits are over- or under-flows?
On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr
On 19/02/14 09:14, Phil Dawes wrote:
I understand, but it seems like a bad tradeoff to me in a language
with safety as a primary feature.
'.lines()' looks like the way to do line iteration in rust, so people
will use it without thinking especially as it is part of the std.io
http://std.io
On 19/02/14 21:44, Kevin Ballard wrote:
My understanding is that .lines() exists primarily to make
quick-and-dirty I/O as easy as it is in, say, a scripting language.
How do scripting languages handle I/O errors when iterating lines? Do
they raise an exception? Perhaps .lines() should fail!()
On 08/02/14 23:35, Alex Crichton wrote:
I'm curious thought what you think is the heavy/verbose aspects of
this? I like common patterns having shortcuts here and there!
When reading the original post, it did occur to me that there should
probably be a readln() equivalent of println(), if only
On 04/02/14 03:49, Bill Myers wrote:
it is guaranteed to happen on all readers
I meant all finite readers, such as those for normal disk files.
What are you getting at here, Bill? I thought you intended the
opposite: to hint that could happen a lot on (async) infinite streams.
--
Lee
On 04/02/14 03:47, Bill Myers wrote:
Are we sure that this is the correct design, as opposed to having read return 0 for EoF or
perhaps returning None with a ResultOptionint, IoError return type?
After all, EOF is unlike all other I/O errors, since it is guaranteed to happen
on all readers,
On 01/02/14 00:09, Tony Arcieri wrote:
On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden leebr...@gmail.com
mailto:leebr...@gmail.com wrote:
This would be counterproductive. If a library cannot be upgraded
to 1.9, or even 2.2, because some app REQUIRES 1.4, then that
causes SERIOUS
On 01/02/14 00:12, Tony Arcieri wrote:
On Fri, Jan 31, 2014 at 4:07 PM, Vladimir Lushnikov
vladi...@slate-project.org mailto:vladi...@slate-project.org wrote:
Just to be clear, I think what you are saying is that you want
version pinning to be dynamic? I.e. when a new version of a
On 01/02/14 09:39, Gaetan wrote:
There is not only API change. Sometime, from a minor version to
another, a feature get silently broken (that is silent regression).
While it might not impact libA which depends on it, but it may fail
libB which also depends on it, but with a previous version.
On 01/02/14 14:55, Vladimir Matveev wrote:
Is it possible at all to find the latest version of a library which is
still compatible completely automatically? Incompatibilites can be
present on logic level, so the compilation wiith incompatible version
will succeed, but the program will work
On 01/02/14 14:49, Vladimir Lushnikov wrote:
Portage has a very similar syntax/way of specifying runtime vs.
build-time dependencies:
http://devmanual.gentoo.org/general-concepts/dependencies/.
Apt doesn't have support for slots and USE flags (code that is
included/excluded at compile time
On 01/02/14 15:48, Vladimir Lushnikov wrote:
I think USE flags are more appropriate for library features (which is
exactly the way portage uses them). So you have your rust app with
conditional code that depends on a particular cfg
(https://github.com/mozilla/rust/wiki/Doc-attributes) and then
Ah, this:
On 01/02/14 15:43, Lee Braiden wrote:
extended_begin()
old_funcs()
new_funcs()
extended_end()
should read more like:
begin()
old_funcs()
extended_begin()
new_funcs()
extended_end()
end()
--
Lee
On 01/02/14 18:54, Gaetan wrote:
why not enforcing in a way or another a API compatibility test suite
for ensuring at least a certain level of compatibility between two
version? I think it is something quite doable, and moreover this would
kinda force the package manager to write unit tests
On 01/02/14 18:54, Gaetan wrote:
why not enforcing in a way or another a API compatibility test suite
for ensuring at least a certain level of compatibility between two
version? I think it is something quite doable, and moreover this would
kinda force the package manager to write unit tests
On 01/02/14 19:32, Vladimir Matveev wrote:
When this API is used directly by the package, then the user *should*
know about it. He's using it, after all.
There are developers (direct library users), and then distro
maintainers/admins/users who need to manage libraries installed on their
On 01/02/14 19:59, Isaac Dupree wrote:
On 02/01/2014 06:27 AM, Matthieu Monrocq wrote:
In short, isn't there a risk of crashes if one accidentally links two
versions of a given library and start exchanging objects ? It seems
impractical to prove that objects created by one version cannot
On 31/01/14 08:05, Gaetan wrote:
Le vendredi 31 janvier 2014, Val Markovic v...@markovic.io
mailto:v...@markovic.io a écrit :
.This is a huge problem in large C++ codebases. It is not fun. An
example: every version of Xerces-C++ puts its code in a new C++
namespace
On 30/01/14 17:18, Jason Fager wrote:
3 extra characters isn't doing anything to stop consenting adults.
Nobody's saying get rid of mutable variables, just that it seems like
a waste of limited resources to figure out how to streamline them when
in general their use should be limited to where
On 26/01/14 15:00, Vladimir Lushnikov wrote:
Here are a couple of observations/comments from a rust lurker:
** And anyway we cannot implement STM in the rust core library I think
Worth noting that Haswell supports STM in hardware:
On 24/01/14 04:37, Steven Fackler wrote:
The deriving infrastructure is implemented as a procedural macro (or
syntax extension) that's built into the compiler. Historically, _all_
syntax extensions had to be built in but that is no longer the case:
https://github.com/mozilla/rust/pull/11151.
On 23/01/14 22:23, Steve Klabnik wrote:
Ehhh, my phrasing on that one was poor. What I was trying to say is
that there are a significant number of users of Rust who do not have
IDEs, and adding anything that would _require_ you to use an IDE with
Rust is a significant drawback.
If an IDE floats
I regularly send/receive things to/from channels at work, and it seems
you can do the same with real-world ports.
I really have no idea what Rust means by a port does, vs. what it means
by a channel, without reading the details in docs. I'd assume the port,
channel ordering reads
On 24/01/14 03:54, Brandon Sanderson wrote:
I would expect Channel::new() to create a channel object that either
lets me send and receive, or lets me get a source and sink to send and
receive with. Borrow rules may prevent this, but my point is that
Channel::new() would generally be
On 24/01/14 03:16, Strahinja Markovic wrote:
On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik
st...@steveklabnik.com mailto:st...@steveklabnik.com wrote:
I don't think that `new` not returning a `Channel` is a big deal.
Conceptually, you are, both ends 'make up' a channel.
I agree
On 24/01/14 13:34, Benjamin Striegel wrote:
Anyway, if we've devolving into bikeshedding then it might be time to
abandon this thread. Usability isn't something that can be crowdsourced.
Well, what you're essentially saying here (assuming you don't mean to
disrespect non-core folks by calling
On 15/01/14 06:34, Corey Richardson wrote:
On Tue, Jan 14, 2014 at 6:54 PM, Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 23:43, Corey Richardson wrote:
This thread is deviating from its purpose. The idea isn't to hash out a
generic build system for all of Rust, merely for the compiler
On 14/01/14 01:50, Palmer Cox wrote:
On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller trop...@bluewin.ch
mailto:trop...@bluewin.ch wrote:
Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Do you know what undefined behavior is? It doesn't mean unspecified.
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the
end what
the official stance should be. There is no valid reason other
package, on any of 3 platforms, and it'll just just
build. The tool is short term convenience, but the data lets me build
short term tools AND long-term infrastructure.
--
Lee
Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex
for creating a prototype deploying duch information... which
would inevitably ask again:
Should Rust have its own build tool, given your proposal of
standardized representational information ? Dealing with such metadata
forces you to design a new system.
Lee Braiden leebr...@gmail.com wrote
:35, Gaetan wrote:
i disagree, the data structure needs to be developed with the majority
of use case possible. you cannot rely on just extending it later
when new feature will be needed, that will NOT work.
-
Gaetan
2014/1/14 Lee Braiden leebr...@gmail.com mailto:leebr...@gmail.com
On 10/01/14 08:16, Gaetan wrote:
I am not in favor of a customized build system. For instance boost
library use their jam build system, and i never figured how to use it
in my projects.
I push to use standard and well proved build system like cmake or
scons, at least for major components.
:34 AM, Lee Braiden leebr...@gmail.com
mailto:leebr...@gmail.com wrote:
On 10/01/14 08:16, Gaetan wrote:
I am not in favor of a customized build system. For instance
boost library use their jam build system, and i never figured how
to use it in my projects.
I push to use
On 10/01/14 19:29, Tony Arcieri wrote:
There's a particular type I'd love to see in core Rust: a bytebuffer
for crypto purposes which automatically provides what I'd call good
crypto hygiene. It'd do the following things:
- Avoid being paged out to swap by use of mlock/VirtualLock
This is a
This may be go nowhere, especially so late in Rust's development, but I
feel like this is an important, relatively small change (though a
high-profile one). I believe it could have a large, positive impact in
terms of targeting new developer communities, gaining more libraries and
Hi Graydon,
On 29/04/13 19:26, Graydon Hoare wrote:
I've read your email a few times and I _think_ it mostly consists of a
request to add catchable exceptions to the language. Which we won't do
(or I won't do, and I will resist strongly as I think it will hurt
users, performance and
On 28/04/13 18:45, Patrick Walton wrote:
If you need to compare a `~str` against a constant string, use .equiv():
use core::cmp::Equiv;
fn main() {
let x = ~foo;
if foo.equiv(x) {
println(yep);
}
}
This should admittedly be imported by default.
Hi all,
This is going to be long, but I've tried to organise my thoughts clearly
and as succinctly as possible.
On 26/04/13 18:06, Patrick Walton wrote:
So here are my ideas. They are very worse-is-better at this point.
* Failing to perform a basic I/O operation should result in a call to
On 27/04/13 12:06, David Bruant wrote:
Le 26/04/2013 23:23, Brian Anderson a écrit :
I do think 50,000 I/O-performing tasks in a 32-bit process is within
our reach. Last year I demonstrated 500,000 simultaneous Rust tasks
(that did nothing but wait) in a 32-bit process, but there have been
Jordi Boggiano Wrote:
Feels weird to have str implement something specific to another module,
but if there is no other way it sounds more user friendly than a
gazillion open_* methods.
A few more comments on other things:
- Streams are great, and the ability to register new stream protocol
On 27/04/13 18:51, Patrick Walton wrote:
On 4/27/13 8:49 AM, Lee Braiden wrote:
This would be a relatively ugly approach, to my way of thinking. Why
should a dead stream be returned at all, if the code to create it
failed? Why should I be able to call write() on something that could
On 06/04/13 03:13, Andres Osinski wrote:
I just wanted to know if anyone was familiar with the FCGI protocol,
and if there's any reference as to how to manage the packing and
unpacking of C data structures, as well as if you know of any
implementation for a similar protocol.
One small
I think the problem is that three different things are needed, and that these
need different (often pre-existing) keywords (or defaults). I'd suggest:
* Global storage by default for consts
* Promotion to global storage where possible and useful, for const and
immutable values
* A shared
47 matches
Mail list logo
