On 06/05/2013 04:04, Graydon Hoare wrote:
How do you fork a requirement? (or discussion thereof?)
How do you fork a design? (or discussion thereof?)
It depends. If there's something specific to comment on, we don't mean
to discourage discussion thereof. Specificity is in the eye of the
beh
On Mon, May 6, 2013 at 12:28 AM, Lindsey Kuper wrote:
> On Sun, May 5, 2013 at 6:17 PM, Andreas Rossberg
> wrote:
> > On May 5, 2013, at 23:54 , Lindsey Kuper wrote:
> >> On Sun, May 5, 2013 at 4:19 PM, Noam Yorav-Raphael
> wrote:
> >>> I have a simple suggestion: the current implementation of
Hi,
Just FYI, I've packaged up rust 0.6 for the OS X apt-like package
management system "fink". I'll keep it updated as releases come out.
I also maintain an unofficial fink binary distribution at
deb http://brendan.users.finkproject.org/10.8 stable main
for 10.8 users, so if you add that to you
On 13-05-06 09:46 AM, Matthieu Monrocq wrote:
> I would therefore propose:
>
> - zip: only on collections of equal length
> - zipcut: stop iteration as soon as the shortest collection is exhausted
> - zipfill: fill the "void" (somehow: default value, Option, ...)
>
> This way we have all 3 varia
On 13-05-06 10:36 AM, Brendan Cully wrote:
> Just FYI, I've packaged up rust 0.6 for the OS X apt-like package
> management system "fink". I'll keep it updated as releases come out.
> I also maintain an unofficial fink binary distribution at
>
> deb http://brendan.users.finkproject.org/10.8 stabl
On Mon, May 6, 2013 at 7:36 PM, Graydon Hoare wrote:
> On 13-05-06 09:46 AM, Matthieu Monrocq wrote:
>
> > I would therefore propose:
> >
> > - zip: only on collections of equal length
> > - zipcut: stop iteration as soon as the shortest collection is exhausted
> > - zipfill: fill the "void" (som
On Mon, May 6, 2013 at 1:36 PM, Graydon Hoare wrote:
> On 13-05-06 09:46 AM, Matthieu Monrocq wrote:
>
>> I would therefore propose:
>>
>> - zip: only on collections of equal length
>> - zipcut: stop iteration as soon as the shortest collection is exhausted
>> - zipfill: fill the "void" (somehow:
On Mon, May 6, 2013 at 1:59 PM, Matthieu Monrocq
wrote:
>
> And then I realized that "zipfill" can be expressed much more cleanly with
> composition instead:
>
> - zip(cycle(short), long) => cycle through short until long is exhausted,
> needs a "stop"
> - zip(cycle(short, long.size()), long) => c
On 13-05-06 07:05 AM, james wrote:
> I think the issue here is that it is not entirely clear what kind of
> problem the libraries are trying to solve, and who for. Plenty of us
> have experience writing server processes and this has historically
> involved quite low-level coding. Its quite reaso
On 13-05-06 11:05 AM, Lindsey Kuper wrote:
> Hm, interesting. Out of curiosity, what is the status of the
> condition system? Is it being used anywhere yet? Is there any
> documentation? A tracking bug?
Implemented and working. It has a number of shortcomings I wish to fix
up eventually. It's
On 13-05-05 03:35 AM, Fabian Deutsch wrote:
> Hey,
>
> just to give the interested Fedora user a hint: I've created a copr ("Fedora
> PPAs") for rust [0]. I'll keep builds for stable releases of rust around.
Thanks! I've added it to the page tracking such things:
https://github.com/mozilla/rust
If you're an Arch user you may have noticed the rust package I already
put in the repositories[1], and I now have a cronjob set up on Arch's
build server to generate a daily build of incoming, originally for the
rusti bot in #rust to use.
You can add it with the following snippet:
[thestinger]
Si
On 13-05-03 07:11 PM, Gábor Lehel wrote:
> So this has been bouncing around in the back of my head, and now actual
> thoughts have congealed there. Essentially, while I think this is a very
> good defense of why Rust doesn't have purity, it's not so convincing to
> me as a defense of why it *shoul
On Mon, May 6, 2013 at 1:36 PM, Graydon Hoare wrote:
> On 13-05-06 09:46 AM, Matthieu Monrocq wrote:
>
>> I would therefore propose:
>>
>> - zip: only on collections of equal length
>> - zipcut: stop iteration as soon as the shortest collection is exhausted
>> - zipfill: fill the "void" (somehow:
On 13-05-04 12:31 AM, Mikhail Zabaluev wrote:
> If you are talking about gettext-like functionality, usually this and
> format strings are thought of as independent processing layers: format
> strings are translated as such and then fed to the formatting function.
> This brings some ramifications,
Le 06/05/2013 21:19, Daniel Micay a écrit :
If you're an Arch user you may have noticed the rust package I already
put in the repositories[1], and I now have a cronjob set up on Arch's
build server to generate a daily build of incoming, originally for the
rusti bot in #rust to use.
This is grea
On 13-05-04 06:54 AM, Devin Jeanpierre wrote:
> I've also added this library page to the wiki:
> https://github.com/mozilla/rust/wiki/Lib-re
This is great! Thanks. I should also point out that you might want to
include / depend on another bug-in-process concerning "raw strings".
It looks like I
Hello,
I'm new to this list and I enjoy programming in Rust.
I have a question.
Does rust's enum type support specifying base type?
C++11 and D support it as below.
// C++11 and D
enum Color: uint { RED = 0xff, GREEN = 0x00ff00, BLUE = 0xff }
// D only
enum Foo: string { AAA = "aaa", B
On Sun, May 5, 2013 at 10:21 PM, NAKASHIMA, Makoto
wrote:
> Hello,
>
> I'm new to this list and I enjoy programming in Rust.
>
> I have a question.
> Does rust's enum type support specifying base type?
>
> C++11 and D support it as below.
>
> // C++11 and D
> enum Color: uint { RED = 0xff, GRE
On Sun, May 5, 2013 at 10:21 PM, NAKASHIMA, Makoto
wrote:
> Hello,
>
> I'm new to this list and I enjoy programming in Rust.
>
> I have a question.
> Does rust's enum type support specifying base type?
> enum Color { RED = 0xffu, GREEN = 0x00ff00u, BLUE = 0xffu }
>
> enum.rs:1:19: 1:28 er
On 05/04/2013 10:13 PM, Thad Guidry wrote:
So, I went back to MinGW and managed to get a compiler chain for
Windows 7 64bit working with mingw64 and using MingGW / Msys and
additionally I was able to get the Wget gui to actually work
correctly... so in essence, Windows users will have a nice
> But you might see more value than I do in keeping the scope of `s`
> strictly contained to the single match-clause, versus overloading a
> (non-`=`) operator/keyword to denote binding. I have no
> counter-argument for that.
I tend to prefer just using scoping because it falls out for free
witho
On 05/06/2013 01:47 PM, Daniel Micay wrote:
They're a tagged union rather than what C/C++/D call an enum. I think
the naming is unfortunate. Probably too late to call them "variant"
though :P.
It's definitely not too late! Let's call them "variants"! :D
Cheers,
Jeaye
On 05/06/2013 12:19 PM, Daniel Micay wrote:
If you're an Arch user you may have noticed the rust package I already
put in the repositories[1], and I now have a cronjob set up on Arch's
build server to generate a daily build of incoming, originally for the
rusti bot in #rust to use.
You can add i
Hello all,
What can I do to help make rusti "halfway tolerable"?
Not to belabor the point, but rusti definitely needs some love -- my git
version of rusti as of one or two days ago always crashes with
"memory_region::~memory_region(): Assertion `false' failed." It will return
the evaluated expres
On Wed, May 1, 2013 at 7:12 PM, Lindsey Kuper wrote:
> To start with, there are no rusti tests [3]. This means that even
> when it's working, it doesn't stay that way for long; for instance, as
> strcat pointed out on IRC today, rusti is more broken now than it was
> in the 0.6 release, due to th
26 matches
Mail list logo
