[rust-dev] Creating an account on discuss.rust-lang.org
How can I create an account on discuss.rust-lang.org? I tried to sign up, but clicking the link in the confirmation email and clicking on “Activate your account” resulted in a response which is literally “['BAD CSRF']”. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Creating an account on discuss.rust-lang.org
* Florian Weimer: How can I create an account on discuss.rust-lang.org? I tried to sign up, but clicking the link in the confirmation email and clicking on “Activate your account” resulted in a response which is literally “['BAD CSRF']”. Never mind, something is wrong with my Firefox ESR profile. Firefox 33 with an empty profile worked. Weird. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cryptol, the language of cryptography
* Steve Klabnik: Bugs with crypto don't often happen because of poorly implemented primitives: they happen when you combine those primitives in bad ways. Formal analysis doesn't help there. That's exactly where formal analysis does help. However, real-world protocols are quite difficult to model, and programmers expect interfaces which make parts of the application part of the model. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The future of M:N threading
* Daniel Micay: Rust's tasks are often called *lightweight* but at least on Linux the only optimization is the lack of preemption. Since segmented stacks have been dropped, the resident/virtual memory usage will be identical. Doesn't the lack of a corresponding kernel thread save something on the kernel side? In the C benchmark, the thread attribute should be created outside the loop. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Danger of throwing exceptions through Rust code
* Daniel Micay: It's undefined behaviour for a C++ function to throw an exception past an `extern C` boundary I don't think this is true. Certainly GCC supports throwing from C as an extension (if the C side has been compiled with -fexceptions), and requires that non-throwing functions are explicitly annotated, even if they have C linkage. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
* Steven Blenkinsop: On Saturday, 19 October 2013, Florian Weimer wrote: The problem is that if err is of type error, err != nil is true after the assignment of a pointer value to err. So the usual error checking idiom doesn't work if your function returns a pointer-to-struct (that implements the error interface) instead of a (relatively opaque) error interface value. Don't do that. Return an error, not a naked error implementation. If people want to inspect it rather than treat it as a string, they'll do a type assertion rather than just a nil check. Then the Go-level interface doesn't tell the programmer that the type assertion continues working (i.e., that there is something to which the caller can attach its extra information). Don't do that. Return either a nil error or a valid value of your error type. Seriously, the nil interface vs nil contents thing is only a tripping point for novices who don't understand what interfaces are, it's not something you run into once you've familiarized yourself with the language. We'll see if that's true once we've got at analyzer that flags this. :-) That's not a chaining mechanism. You're going to need to explain what you mean by this, then, and how it would apply to Rust. Note that if it's something very particular to how Go code is written, it's probably not constructive here. Java exceptions have a getCause() mechanism which returns another exception. When you've got a piece of got that needs to provide further context to exceptions that might be thrown by lower layers, it can at a catch-all exception handler (well, usually for Exception, not Throwable, so it's not quite catch-all) and throw a new exception, specifying the existing exception as a cuase. Traceback printing uses this information and suppresses identical parts of the call stack, which often results in fairly useful output, without resorting to more elaborate debugging mechanisms. In contrast, I'm worried that error value threading (even when done properly, not swallowing any errors) destroys potentially valuable information about the context while the stack is (manually) unwound, leaving little more than a bare error message when it's finally reported or logged. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
* Patrick Walton: * I can pretty much guarantee you that that simple of a static analysis to determine stack size is going to fail on any reasonable program. It's needed to show total correctness, and often done with tool support in the embedded space. GCC has some support for it. Obviously, it only works with fairly restricted language subsets, but such is life if you're after verifiable total correctness. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
* Patrick Walton: In other words: Why bet, as Go did, that the failure case won't happen much in practice when we can adopt an error-handling strategy that rules it out entirely? Uh-oh, I thought that Rust has ruled out error handling constructs based on implicit control flow? :-) But seriously, *this* particular issue is pretty well addressed by (unchecked) exceptions. They definitely encourage developers not to neglect error propagation. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
* Igor Bukanov: So the Go style is to call a function, check if the was an error, update the error object (or create a new wrapping the old one) with extra information relevant to the current call stack frame and propagate the updated error object to the caller. It's more common to simply return the object. Due to some obscure feature of Go's type system, error values have to be interfaces and cannot be struct types, so I have not seen anyone trying to updating an existing error. Wrapping might happen, but there is no general chaining mechanism like there is in Java. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
* Chris Morgan: I would love this to be the case. It's the biggest problem I had with Go's error handling: that it's far too easy to just ignore a return value accidentally. I did an informal study some time ago, and it does not appear to be that common a mistake. (I was biased and tried to prove that the current state of affairs what bad, but the results weren't convincing.) It only happens when there are no results whatsoever. If there are results that need processing, programmers do some form of error handling or threading. There is, however, one major design blunder. Some of the I/O interfaces (Reader, ReaderAt etc.) do not follow the rest of the standard library in treating the result/error return as a sum type. In the rest of the library, you have to check the error first because it is often not possible to see from the result itself that it is part of an error (say, the value 0 from an string-to-inter parsing routine). With I/O, you have to check the result first because some of the interfaces are specified to return both data and an error. Here's an example for io.Reader: http://golang.org/pkg/io/#Reader Rust shouldn't have this problem if it uses a proper sum type, and even with Go the language, it would have been possible to avoid this mess with a better choice in Go the library. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
* Patrick Walton: On the other hand, Cindy Rubio-González's work shows that in the Linux kernel, forgetting to handle error codes is *extremely* common. http://www.eecs.berkeley.edu/~rubio/ I don't see anything fundamentally different with Go's approach that will lead to a different outcome. The kernel usually passes results by storing them in an existing object because allocation by the callee is less efficient and impossible in many contexts. Go has garbage collection, and returning a new object and an error return value is the more common style. The result-plus-error case has a much better chance of being handled correctly. Go also has exceptions (for signaling certain errors). I'm not sure if it deals with memory allocation failures gracefully. If it doesn't, that would eliminate a fair chunk of kernel error handling, too. So in short, Go is quite different. :-) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Calling back into Rust from C code
* Skirmantas Kligys: I am trying to write a native wrapper for https://github.com/pascalj/rust-expat (BTW, if there is a native Rust XML parser, I am interested to hear about it, did not find it). I have trouble calling back into Rust from C code: It's probably better to avoid calling back into Rust, storing events in a buffer in C callbacks. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] No range integer type? Saftey beyond memory?
* Graydon Hoare: How much of a performance penalty is it worth? I believe you can trap this in C presently with a gcc flag too (-ftrapv); but it's a flag rarely turned on. GCC cannot use the OF flag, but LLVM has overflow-checking instructions, and Clang actually emits instructions using the OF flag for operator new[]: http://gcc.gnu.org/ml/gcc/2010-12/msg00154.html With undefined or trapping overflow, it's even more difficult to write overflow checks. GNAT addresses this by offering a mode which evaluates comparisons with infinite precision (with appropriate optimizations for common cases where full bignum arithmetic is not necessary). Ada allows suppressing an overflow exception as long as the mathematically correct result is produced. For a memory-safe language such as Java where pointer arithmetic or equivalents are rare (although some native code wrappers contain security-relevant range checks in Java code), overflow checking for integer types is not absolutely essential. For writing unsafe modules, I imagine overflow checks whould be rather helpful. For Rust, the interaction with resource management would be tricky, I think. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] net::tcp::TcpSocket slow?
* Michael Neumann: I am writing a redis client [1] for rust but somehow TCP performance seems to be veery slow. I basically just sent a string to redis and read the response (I commented out parsing). Doing this 10_000 times takes about 4.5 seconds, while doing the same in Ruby takes just 0.7 seconds. Perhaps you just need to disable the Nagle algorithm (that is, enable the TCP_NODELAY socket option). I'm not sure if Rust uses the code for that in libuv. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Tutorial issues
I went over tutorial and spotted a few typos (see below).
I think the SHA-1 example shouldn't use the static buffer because it
is not task-safe.
More significantly, the gettimeofday example still uses the wrong
types for time_t and suseconds_t. time_t is usually signed and not
always 64 bit (or the size of a machine word). suseconds_t can be a
32-bit type even on 64-bit machines, and the padding is in the wrong
place on big-endian machines. Not sure if rustc already works on
anything besides i386 and amd64 on GNU libc platforms. But even to
support these two, you need this:
type timeval = {mut tv_sec: c_long, mut tv_usec: c_long};
time_t and suseconds_t are two of the most problematic types for FFI.
It's difficult to find structs in POSIX which are essentially fixed.
struct pollfd appears to be one such type, but the example would have
to be larger.
diff --git a/doc/tutorial.md b/doc/tutorial.md
index ed32100..78f41e3 100644
--- a/doc/tutorial.md
+++ b/doc/tutorial.md
@@ -350,7 +350,7 @@ more underscores.
The double-colon (`::`) is used as a module separator, so
`io::println` means 'the thing named `println` in the module
-named `io`'.
+named `io`.
Rust will normally emit warnings about unused variables. These can be
suppressed by using a variable name that starts with an underscore.
@@ -1413,7 +1413,7 @@ let exchange_crayons: ~[crayon] = ~[banana_mania, beaver,
bittersweet];
but is deprecated. In the future it will probably represent some
reasonable default vector type.
- Unique vectors are the currently-recomended vector type for general
+ Unique vectors are the currently-recommended vector type for general
use as they are the most tested and well-supported by existing
libraries. There will be a gradual shift toward using more
stack and local vectors in the coming releases.
@@ -2814,7 +2814,7 @@ C functions often take pointers to structs as arguments.
Since Rust
records are binary-compatible with C structs, Rust programs can call
such functions directly.
-This program uses the Posix function `gettimeofday` to get a
+This program uses the POSIX function `gettimeofday` to get a
microsecond-resolution timer.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Concurrency and synchronous blocking
* Ziad Hatahet: Ah, you mean after repeated invocations of the containing function in case the timeout event keeps firing? Yes, that's the problem. In most cases I've seen, the cause for a timeout does not go away quickly, so such a programming pattern tends to spread the congestion even further. I think there has been quite a bit of research in the Erlang context how processes can avoid increasing load in an already overloaded situation, but I can't find the papers right now. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Concurrency and synchronous blocking
* David Bruant:
Most of my concerns are appearant in the following piece of Go code
(32'41'' in the video):
c:= make(chan Result)
go func() { c - Web(query) } ()
go func() { c - Image(query) } ()
go func() { c - Video(query) } ()
timeout := time.After(80*time.Milliseconds)
for i:=0; i3; i++ {
select{
case result := -c
results = append(results, result)
case - timeout
fmt.Println(timed out);
return
}
}
return
This approach is fundamentally broken. If the timeout ever kicks in,
goroutines will pile up without bounds. In the current Go
implementation, the timeout has to be moved inside the goroutines.
(Theoretically, Go could support cancellation of goroutines, but this
is something really thorny, carries a distributed overhead and does
not seem to be particularly attractive.)
My analysis goes as follow:
Due to synchronous wait, the 3 server queries have to be done in 3
goroutines, otherwise, they would block the main goroutine or one
another. Each goroutine costs something (both for memory creation and
certainly scheduling too).
Goroutine allocation is very cheap (or it can be made so at least).
Actually, part of the allocation cost is distributed throughout the
program: segmented stacks and the increased size of the overall root
set.
The scheduling overhead is low if there is just one actual thread
available for executing goroutines. The select will switch to one of
the newly created goroutines and execute that until it blocks on the
connect. There is no preemption, so no cycles are wasted on that. It
should be possible to avoid context switches in the same way as the
leader/follower pattern does. (I have not checked if the current
implementation does that.)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Concurrency and synchronous blocking
* Ziad Hatahet: On Wed, Jul 11, 2012 at 10:27 AM, Florian Weimer f...@deneb.enyo.de wrote: This approach is fundamentally broken. If the timeout ever kicks in, goroutines will pile up without bounds. I just want to be clear on your comment. You mean the goroutines would pile up, or the channel will grow without bounds? The goroutines would pile up. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Brace-free if and alt
* Patrick Walton: // after: if foo() == bar then 10 else 20 This paves the way to: if foo() == bar then f(); g(); I expect that if braces are optional, some users will want an option to make them mandatory again. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Addressing the hashtable problem with type classes
* Niko Matsakis: Here is a proposal to work around a potentially serious problem with the modular type classes we have been discussing. The problem, as explained, is that collections (and possibly other data structures) can lose coherence if they are used with incompatible implementations of type classes like `hashable`. Is this to related to Weirich et al., Generative Type Abstraction and Type-level Computation, in the sense that it is a precursor of the problems discussed there? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unicode identifiers
* Igor Bukanov: With most fonts it is not possible to see that the following ES fragment should alert 1, not 2. I guess such problems are not considered high on the list of language designs. javascript:var a = 1; а = 2; alert(a); Same problem with ASCII and some fonts: javascript:var l = 1; I = 2; alert(l); (Gill Sans comes to my mind, but probably no one uses that for programming.) AI05-0227-1 is relevant in this context because it shows the difficulties that come with non-ASCII identifiers in some contexts: http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0227-1.txt?rev=HEAD To my knowledge, no Ada implementation makes a decent attempt at getting this right. There does not seem to be much commercial demand, so compiler vendors have different priorities. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
