Sorry... in the screenshot "Current" column shows what I have installed
"currently".
On Wed, May 1, 2013 at 11:03 PM, Thad Guidry wrote:
> I have mingw64 installed. See my Cygwin Setup screenshot here:
> https://docs.google.com/file/d/0B533WzlrxWraSHgzdVpGM29WQ1k/edit?usp=sharing
>
>
> On Wed
I have mingw64 installed. See my Cygwin Setup screenshot here:
https://docs.google.com/file/d/0B533WzlrxWraSHgzdVpGM29WQ1k/edit?usp=sharing
On Wed, May 1, 2013 at 10:56 PM, Corey Richardson wrote:
> On Wed, May 1, 2013 at 11:49 PM, Thad Guidry wrote:
> > This FAQ has most of those answers, Co
On Wed, May 1, 2013 at 11:49 PM, Thad Guidry wrote:
> This FAQ has most of those answers, Corey, just scroll down it to see the
> API and Programming Questions : http://cygwin.com/faq/
>
So from http://cygwin.com/faq/faq-nochunks.html#faq.programming.win32-no-cygwin,
perhaps you should try using
This FAQ has most of those answers, Corey, just scroll down it to see the
API and Programming Questions : http://cygwin.com/faq/
On Wed, May 1, 2013 at 10:47 PM, Corey Richardson wrote:
> On Wed, May 1, 2013 at 11:34 PM, Thad Guidry wrote:
> > Thanks to the incredible outpouring of support fro
On Wed, May 1, 2013 at 11:34 PM, Thad Guidry wrote:
> Thanks to the incredible outpouring of support from the community on IRC to
> help me get Cygwin supported, tonight I had somewhat better success... as I
> have been patching my way through Rust's source with the help from those
> incredible IR
Thanks to the incredible outpouring of support from the community on IRC to
help me get Cygwin supported, tonight I had somewhat better success... as I
have been patching my way through Rust's source with the help from those
incredible IRC folks. Thanks guys and gals !
We have been adding if defi
> However, is there an alternative that does not introduce (ref)
> indirection? Something that would make s in the code below be of type
> &str instead of ~str?
There is not, today. This is precisely what the recent thread
"dynamically sized types, revisited" is discussing, however. If that
pro
> Concerning the 'Sized' kind, I wonder if it can ever be implied,
> somehow, due to the use of T in [T]. Like it's pretty much mandatory if
> you do:
>
> impl foo for [T] {
> }
>
> that the there actually be right? You can't denote the [T]
> type for any non-Sized T. Not that I'm really k
On Thu, May 02, 2013 at 01:25:43AM +0200, Gábor Lehel wrote:
> Yep, that's what I was figuring. I'm not sure what "lvalue context" means
> precisely -- it's not actually on the left hand side of anything here, and
> the other example below where it *is* on the LHS is illegal -- but the
> shape of t
John,
I would suggest requiring *exactly* three slashes for a doc comment (or
*exactly* two stars for a /** -- */ style doc comment). This matches
with Doxygen's parsing (I think), and makes both the examples below
parse correctly.
Erik
On 5/1/2013 11:29 AM, John Clements wrote:
> Currently, the
On 13-05-01 04:57 PM, Niko Matsakis wrote:
> On Wed, May 01, 2013 at 11:49:10AM -0700, Graydon Hoare wrote:
>> 1. Why _exactly_ (if it's possible to reconstruct) did this factoring
>> not work last time, and what has changed since?
>
> AFAIK we never looked deeply into changing the represen
> Not sure how this would prevent mutation of keys after they've been placed
> in the hash. Could you please point me to an example?
strcat's example is fine. Basically, when you create an immutable,
borrowed pointer, you also promise to keep that data immutable for the
lifetime of the pointer---
On Wed, May 01, 2013 at 11:49:10AM -0700, Graydon Hoare wrote:
> 1. Why _exactly_ (if it's possible to reconstruct) did this factoring
> not work last time, and what has changed since?
AFAIK we never looked deeply into changing the representation of ~[]
and @[] such that they are represente
On Wed, May 1, 2013 at 4:50 PM, Niko Matsakis wrote:
> On Wed, May 01, 2013 at 02:39:12PM +0200, Gábor Lehel wrote:
>
> > So *if* the plan ends up working out, then taking the second part of my
> > earlier proposal:
> >
> > > You might also have a rule whereby dereferencing a variable when the
>
Hi everyone,
I'd like to give rusti more attention and make it actually useful and
usable. As I'm sure we're all aware, a good REPL is especially
valuable for a new and not-yet-well-documented language. Various open
bugs [0, 1, 2] illustrate some of the current problems with rusti, and
astriean
Hello everybody,
I am to new to this list (and to the very promising language that Rust
definitely is).
While learning Rust and writing my first applications in it I stumbled
upon the problem of matching an owned box to a variable pattern. I am
wondering if there is any syntax to convert an ow
On Wed, May 1, 2013 at 6:13 PM, Graydon Hoare wrote:
> On 13-05-01 02:47 PM, Daniel Micay wrote:
>> On Wed, May 1, 2013 at 5:44 PM, John Clements
>> wrote:
>>>
>>> On May 1, 2013, at 10:57 AM, Graydon Hoare wrote:
>>>
On 13-05-01 10:32 AM, Lucian Branescu wrote:
> Is it too late/undesir
On 13-05-01 02:47 PM, Daniel Micay wrote:
> On Wed, May 1, 2013 at 5:44 PM, John Clements
> wrote:
>>
>> On May 1, 2013, at 10:57 AM, Graydon Hoare wrote:
>>
>>> On 13-05-01 10:32 AM, Lucian Branescu wrote:
Is it too late/undesirable to have an explicit, separate syntax for
docstrings,
On Wed, May 1, 2013 at 5:44 PM, John Clements wrote:
>
> On May 1, 2013, at 10:57 AM, Graydon Hoare wrote:
>
>> On 13-05-01 10:32 AM, Lucian Branescu wrote:
>>> Is it too late/undesirable to have an explicit, separate syntax for
>>> docstrings, a bit like Lisps/Python?
>>
>> We have one: #[doc="..
On Wed, May 1, 2013 at 5:37 PM, Vadim wrote:
> Thanks for your response Niko. A couple more questions if you don't mind:
>
> On Wed, May 1, 2013 at 10:51 AM, Niko Matsakis wrote:
>>
>> Hello,
>>
>> Unfortunately, I accidentally deleted a message from Vadim that I
>> wanted to reply to. However,
On May 1, 2013, at 10:57 AM, Graydon Hoare wrote:
> On 13-05-01 10:32 AM, Lucian Branescu wrote:
>> Is it too late/undesirable to have an explicit, separate syntax for
>> docstrings, a bit like Lisps/Python?
>
> We have one: #[doc="..."]
>
> Doc comments are an alternative syntax for the same a
Thanks for your response Niko. A couple more questions if you don't mind:
On Wed, May 1, 2013 at 10:51 AM, Niko Matsakis wrote:
> Hello,
>
> Unfortunately, I accidentally deleted a message from Vadim that I
> wanted to reply to. However, it had strayed from the topic of the
> thread anyhow (whi
On 13-05-01 03:51 AM, Niko Matsakis wrote:
> Hello everyone,
>
> I just thought I'd point out a recent blog post that I think may be of
> general interest:
>
> http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/
>
> I'm kind of excited about this idea. Maybe one of y
On 13-05-01 10:32 AM, Lucian Branescu wrote:
> Is it too late/undesirable to have an explicit, separate syntax for
> docstrings, a bit like Lisps/Python?
We have one: #[doc="..."]
Doc comments are an alternative syntax for the same attribute because
nobody liked that.
-Graydon
_
Oops, it seems like my patch (6d98ca9) had a bug. For anyone
interested, a small update to `parse::lexer::is_line_non_doc_comment`
function will fix it. (Right now I don't have a compilation
environment, so it's my guess.)
That said, I don't like doc comments being translated to decorators at
all,
Hello,
Unfortunately, I accidentally deleted a message from Vadim that I
wanted to reply to. However, it had strayed from the topic of the
thread anyhow (which was called "sub-grammar for range pattern
constants") so I'll just startup a new thread here.
Vadim wrote:
> - Does "immutable" mean tha
I'm for this.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Is it too late/undesirable to have an explicit, separate syntax for
docstrings, a bit like Lisps/Python?
On 1 May 2013 18:32, Patrick Walton wrote:
> On 5/1/13 10:29 AM, John Clements wrote:
>
>> Currently, the set of doc comments includes (among other things)
>> lines beginning with three slas
On 5/1/13 10:29 AM, John Clements wrote:
Currently, the set of doc comments includes (among other things)
lines beginning with three slashes, *unless* they're entirely
slashes. Presumably, this is to ensure that things like
/ // Time to go get some coffee!
... aren't p
Currently, the set of doc comments includes (among other things) lines
beginning with three slashes, *unless* they're entirely slashes. Presumably,
this is to ensure that things like
/
// Time to go get some coffee!
... aren't parsed as two doc comments consisting enti
Forgive me for cross-posting. The message below sheds light on some hard-earned
lessons about versioning in the Racket package system. There may well be large
differences between Rust and Racket in this regard, but the decoupling of
version numbers from in-code dependencies was, I believe, an in
On Wed, May 01, 2013 at 02:39:12PM +0200, Gábor Lehel wrote:
> I also just read Niko's blog post, and I'm not sure which thread to reply
> in (or who to reply to), but I guess I'll do it here. Niko's message here
> beforehand was kind of expectations-downplaying, but reading the blog post,
> his pr
On Tue, Apr 30, 2013 at 9:22 PM, Graydon Hoare wrote:
> On 30/04/2013 11:26 AM, Gábor Lehel wrote:
>
> Couldn't this be relaxed? In other words allow dynamically sized `str`
>> as a type (and perhaps similarly for other dynamically sized types), but
>> prohibit those things specifically which wo
Hello everyone,
I just thought I'd point out a recent blog post that I think may be of
general interest:
http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/
I'm kind of excited about this idea. Maybe one of you can poke a hole
in it. In any case, it describes a way
34 matches
Mail list logo
