> I may have misunderstood how to use it, but I typed '([A])->bool' into
> the web interface and expected to see vec::is_empty (amongst others)
> but it just drew a blank.
Nope, just a bug (which should be fixed now) - I just rewrote the parsing code
(such as it is) from an extremely simplistic i
1. "Protect/handle", a.k.a. "make it look like try/catch": this version
pursues the arrangement with protected-code coming first and handlers
coming second. To do this, the protected-code has to be suspended in a
closure, which is then passed to a temporary struct, which is
responsible for both
I've started playing with C++ AMP and its really very straightforward,
if currently trting that I can't get full double support on Win7.
If you can support attributes that do the equivalent of restrict (and
the key here is that the attribute is involved in overload resolution)
then it could be
On 2012-10-19, at 03:05 , Daniel Patterson wrote:
> I'm announcing an initial version of an API search tool for Rust called
> Rustle. It is inspired by the api search tool for Haskell
> called Hoogle (http://www.haskell.org/hoogle).
Haskell's community also has Hayoo[0], which is less focused o
On Sat, Oct 20, 2012 at 7:33 PM, Graydon Hoare wrote:
> On 20/10/2012 10:48 AM, Peter Hull wrote:
> I'm not sure where this comes from; I have no reason to think Rust would
> resist intellisense-like tooling. It might require running portions of
> the resolver or typechecker, but so does any such
Sorry, sent to Graydon directly instead of to the list.
Pete
-- Forwarded message --
From: Peter Hull
Date: Sat, Oct 20, 2012 at 6:48 PM
Subject: Re: [rust-dev] Announce: rustle, an api search tool
To: Graydon Hoare
> On 12-10-18 06:05 PM, Daniel Patterson wrote:
>
>> To try it
On 20/10/2012 10:48 AM, Peter Hull wrote:
> Graydon, is all the required information already provided by libsyntax
> or will Daniel indeed have to wait for a librustdoc before he can stop
> scraping the HTML?
Rustdoc should become a library in the near-ish future; but its source
is in-tree and av
On 20/10/2012 5:31 AM, Matthieu Monrocq wrote:
> I just realized I had missed a point, which is somewhat similar to what
> Gareth raised: composability.
Yeah. None of them have _great_ composability but it's actually the main
thing pressing me towards #3. There are composition hazards in #1 and
#
On 20/10/2012 4:19 AM, Matthieu Monrocq wrote:
> This seems heavily influenced by Lisp's Conditions & Restarts[1] (not
> that I have used Lisp before though, but I *am* interesting in error
> handling strategies),
Similar. A bit less involved. But yes. Resumable at-site condition
systems have a
On Sat, Oct 20, 2012 at 1:37 PM, Gareth Smith
wrote:
> Option 3 looks prettiest to me, but I like that in Option 1 the
> error-raising code comes before the error-handling code (based on
> experience with other languages). This might not be an issue in practice.
>
> I am not sure how I like Option
Option 3 looks prettiest to me, but I like that in Option 1 the
error-raising code comes before the error-handling code (based on
experience with other languages). This might not be an issue in practice.
I am not sure how I like Option 3 with a more complex trap block:
OutOfKittens.trap(|t|
On Sat, Oct 20, 2012 at 11:16 AM, James Boyden wrote:
> On Sat, Oct 20, 2012 at 10:48 AM, Graydon Hoare
> wrote:
>
> > Some references to the lurking plan here:
> > https://mail.mozilla.org/pipermail/rust-dev/2011-November/000999.html
>
> Firstly, I'd like to express my appreciation for the clea
On Sat, Oct 20, 2012 at 10:48 AM, Graydon Hoare wrote:
> Some references to the lurking plan here:
> https://mail.mozilla.org/pipermail/rust-dev/2011-November/000999.html
Firstly, I'd like to express my appreciation for the clear reasoning
in this linked post.
I found the arguments clear and co
13 matches
Mail list logo
