On 13-08-25 07:25 PM, Brendan Zabarauskas wrote:
brson and the Style Guide seem to favour stacked line comments:
https://github.com/mozilla/rust/wiki/Note-style-guide#comments
Reason: it avoids the debate about whether to put stars on every line, etc.
is an important point. I was trying to
On 13-08-23 09:49 AM, Oren Ben-Kiki wrote:
Yes, Rust has a `deriving` attribute one can attach to types (for stuff
like `Eq`, `Ord`, etc.).
That said, as long as the vtable is already there, I think Rust should
do what Haskell is moving to (automatically `derive Typeable`) - that
is,
On 13-08-23 11:08 AM, Oren Ben-Kiki wrote:
Interesting - I see std::intrinsics::unstable::get_tydescrT - *TyDescr...
Two questions:
- Can this be used for a quick type equality check (same pointer =
same type)?
No, as I said, it does not support efficient type-equality. We don't
normalize
On 13-08-23 11:16 AM, Patrick Walton wrote:
On 8/23/13 11:15 AM, Graydon Hoare wrote:
get_tydesc::T(). This is the foo vs foo:: syntax papercut. Gets
everyone, sorry. It's the price of using for type parameters rather
than []. We need a better error message for it.
Actually, [] would have
On 13-08-23 11:41 AM, Bill Myers wrote:
2. Distribute compilations and tests across a cluster of machines (like
distcc)
Compilation is 99% serial (the only things that happen in parallel
are rustpkg and rustdoc etc at the end, and they are almost nothing),
though tests could be
On 13-08-23 12:16 PM, Simon Sapin wrote:
Le 23/08/2013 19:47, Matthieu Monrocq a écrit :
The most trivial mistake is to have `+=` and `+` defined so that `a +=
5` has a different result than `a = a + 5`
Would it work to make `a += b` always expand to `a = a + b`, and have
that not be
On 13-08-20 09:15 PM, Brian Anderson wrote:
I tried reproducing the regression with a subset of the run-pass tests
earlier and failed, so tonight I tried harder by running all of make
check like `make check CFG_ENABLE_VALGRIND=1 RUST_THREADS=1` (after
previously building the compiler with
On 13-08-21 05:53 PM, Bill Myers wrote:
Have you considered the following non-specific quick fixes?
1. Build on a ramfs/ramdisk
Not I/O bound.
2. Distribute compilations and tests across a cluster of machines (like
distcc)
Already doing what we can here. The remainder doesn't parallelize
On 13-08-21 07:47 PM, Corey Richardson wrote:
- Metadata is large. It is multiple megabytes of data (uncompressed.
compressed as of now it is 749K) for libstd. I'm not sure whether we
are encoding too much data or if it's exactly what we need, but this
is a very large constant that every
Hi,
We had a meeting today that was mostly about cycle time. Integrating a
change on the rust repo currently takes about 2 hours, which is still
far too much. We've tried approaching this from a variety of
perspectives in the past and I feel like possibly I've not conveyed the
cost and work
Hi,
The bors queue length recently caused us to overflow the github API rate
limit. I will reduce the poll frequency (and possibly look into getting
us a proper API token), but it would also help if people could regularly
clean out stale or bad requests and/or merge larger groups of their PRs
Given that many people have noted that they've never used it in python,
and nobody seems to agree on what the intuitive behavior for it would
be, and all such behaviors can be implemented via macros, I think we'll
pass.
-Graydon
___
Rust-dev mailing
I'm happy to reserve 'yield' as a keyword for future experiments, but I
don't think we have either scope or a coherent enough design to commit
to doing anything particular with it at the moment. We're generally
trying to get all the things we have semi-working or agreed-to-be-done
*done* rather
On 13-08-12 02:42 PM, Michael Woerister wrote:
I know that the feature request (at:
https://github.com/mozilla/rust/issues/7746) is assigned to the far
future milestone. This thread and my blog series was intended to
collect information about the topic and get some light discussion about
On 13-08-08 11:54 AM, Brian Anderson wrote:
Hey there.
Today we've turned on the new runtime, written in Rust, for all Rust
programs. This completely replaces the old task scheduler written in
C++. This is an important milestone in the ongoing [I/O rewrite], and
there are a lot of feature and
On 13-08-05 08:06 PM, Brendan Zabarauskas wrote:
That was my understanding. Without knowing much about the compiler, `mod`
seems to declare an item. It would be weird to allow imports between item
declarations.
Yes. 'mod foo' is a definition just like 'mod foo { ... }' and will
shadow any
On 13-08-05 03:47 PM, Benjamin Striegel wrote:
I'm mostly indifferent. The only reason I slightly prefer the .NET
convention is to avoid confusion with statics (`GC` could easily be a
static, `Gc` could not).
+1 to having Graydon flip a coin. That way we can shift all blame to the
fundamental
On 13-07-29 04:29 PM, Wojciech Miłkowski wrote:
Hi,
I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn
On 13-07-30 08:53 AM, Andreas Rossberg wrote:
Let a lurker nitpick on a false dichotomy in this comparison. There are three
separate things going on that the current discussion seems to confuse:
1. The syntax of type annotations.
2. The syntax of function types.
3. The syntax of function
On 13-07-30 10:17 AM, Patrick Walton wrote:
On 7/30/13 10:05 AM, Graydon Hoare wrote:
Trickier call. We don't allow type ascription inside patterns, only at
the outermost level. I think we found that our grammars were
sufficiently similar that intermixing them inside one another produced
On 13-07-30 11:16 AM, Patrick Walton wrote:
On 7/30/13 10:39 AM, Graydon Hoare wrote:
Really? How would you resolve it? You have to decide after seeing {x:
which grammar to switch into parsing. Currently we go with the pattern
grammar there.
Struct literals have to be prefixed with the type
On 13-07-30 01:03 PM, Andreas Rossberg wrote:
Ah, actually, this asymmetry, as you call it, is also standard, and quite
relevant. It's rather Haskell's pun on using the same syntax for tuples and
their classifier that is an outlier (and arguably a wart). The problem with
it is that it is
On 13-07-28 09:24 PM, Alex Crichton wrote:
I would love comments/suggestions on this system. I think that this takes into
account almost all of the feedback which I've received about how formatting
strings should work, but extra sets of eyes are always useful!
In general I'm really happy
On 13-07-28 04:06 PM, Steven Ashley wrote:
{0:(
if count == 0 then (You have no messages.)
else (You have {count:#} messages.)
)}
That's exactly the case that the nested pluralization forms are for.
Read the docs on MessageFormat. They've been working on this problem
space for
Hi,
The buildbot upgrade is more-or-less done (I need to do some no-op
upgrades on the slaves today but this carries no risk); we're now on
buildbot 0.8.8rc1. If you see any behavior that worries you or appears
to be a new error, please let me know. For the most part it should
behave as
On 13-07-25 05:42 AM, Benjamin Striegel wrote:
As a professional Javascripter, I implore you keep `do` as it is. It
really and truly is a world of difference between:
do foo {
...
}
and:
foo(|| {
...
});
It's one of my favorite features of Rust,
On 13-07-25 08:34 AM, Simon Sapin wrote:
Le 25/07/2013 01:56, Graydon Hoare a écrit :
for pattern in expr { ... }
Yes please.
- The 'do' form starts to look a little lonely / incongruous. We use
it presently for passing-in-a-closure when a function takes an
optional
As it's a little quiet this week (many people away at OSCON) I'm going
to take the opportunity to upgrade buildbot (we're running a version
from 2010). Hopefully it shouldn't be offline for long, assuming I get a
new instance running reasonably well; but there might be some disruption
to landings
On 13-07-24 09:33 AM, Brendan Zabarauskas wrote:
On 25/07/2013, at 2:15 AM, Evan Martin mart...@danga.com
mailto:mart...@danga.com wrote:
Is an Optionu8 implemented as a pair of (type, value) or is it
packed into a single word?
A quick test shows:
rusti std::sys::size_of::Optionu8()
Hi,
We had some discussion recently about reforming the for-loop syntax
since we'll be switching it to external iterators and it's a bit
deceptive to the user to be writing a lambda-pattern there. Many people
have suggested we use a simple and familiar:
for pattern in expr { ... }
form.
On 13-07-18 06:36 AM, Benjamin Striegel wrote:
I agree that this is a huge headache waiting to happen. It's our own
version of the const-correctness problem.
It also occurs with other obvious utility impls like totalord and
iterbytes, when someone decides to use a struct as a key in a hash or
On 13-07-17 09:07 AM, Benjamin Striegel wrote:
This is all fantastic, especially the codegen tests. Does buildbot
record the codegen tests in a way such that they're potentially
trackable on isrustfastyet?
Not quite yet, but (when I make time to finish this part) buildbot will
grab all the
On 13-07-17 03:50 AM, Niko Matsakis wrote:
On Tue, Jul 16, 2013 at 11:52:08PM -0700, Patrick Walton wrote:
Just a quick note that I have a pull request in the queue to remove
the copy expression in favor of the clone method. Please try to
avoid using copy in your pull requests, or you will
On 13-07-17 10:37 AM, Brian Anderson wrote:
Uh, that math was wrong. num_cpus * 2 * num_cpus * 4 * 2 = 256 :)
I'm a bit confused here. Is the arithmetic based on the notion of
num_cpus * 4 test-tasks running at once (let's say 32 tasks, on an
8-way machine) all doing MT-scheduler testing at
On 13-07-17 11:37 AM, Brian Anderson wrote:
That does not apply to stdtest, where the scheduler tests are located,
but only to the tests run by the compiletest driver.
Oh yeah, failing in stdtest, sorry. Misread.
-Graydon
___
Rust-dev mailing list
Hi,
I've added some new machinery to the testing systems in rust and wanted
to draw a little attention to them. At least this will all be true
shortly when https://github.com/mozilla/rust/pull/7829 lands.
They're (lightly) documented at the bottom of:
On 13-07-14 11:30 PM, Jack Moffitt wrote:
Without format strings as the primary way to do output, I think we'll
fall down really short on the ability to do internationalization.
I didn't suggest we remove fmt!, but that we make the default println!
not do formatted output by itself. My
On 13-07-15 10:43 AM, Michael Woerister wrote:
Thanks for your response. I'll give it a try and hopefully you'll see
some corresponding pull requests over the next few days.
I suspect you'll want to make a trait `Spanned` that the various
spanned-types implement, such that code that
On 13-07-07 08:06 PM, Bennie Kloosteman wrote:
You think Linux is not well-engineered?
Nope .. its the same piece of 1970s crap that all the other popular OS
use , with trivial differences people make a bit deal about..
On 13-07-15 04:05 AM, Bennie Kloosteman wrote:
Go and D are basically C
On 13-07-14 10:16 AM, Daniel Micay wrote:
Without format strings as the primary way to do output, I think we'll
fall down really short on the ability to do internationalization.
I agree. I18n requires the ability to switch around parameter-order
substantially across a large-ish
On 13-07-07 03:48 AM, Matthieu Monrocq wrote:
There is a specific rule in the C++ specification to address
temporaries: they should live up until the end of the full expression
they are part of.
Yeah. We need to nail this down, it's been open for a while, is on
milestone #1:
I should have asked earlier, but better late than never: this
conversation's gone off the rails and well into the non-courteous,
non-productive territory we ask people to keep off our lists. See
Conduct here:
https://github.com/mozilla/rust/wiki/Note-development-policy
We're going to support
It seems that rusti is not stable enough to be part of normal
integration tests; completely unrelated changes are causing it to fail
more often than not, and bors is backing up with changes that are
otherwise fine.
I discussed with folks on IRC and the consensus seemed to be disabling
rusti
On 13-07-04 07:30 PM, Thad Guidry wrote:
On Windows there's a better way than DWARF or SJLJ to catch exceptions I
learned today. (I have no idea what I am talking about, but here goes
from what I read...)
Windows uses it's own exception handling mechanism known as SEH. GCC
supports SEH on
On 13-07-04 10:54 PM, james wrote:
If the segments are allocated from a selection of standard sizes, can
you not have a (hardware) thread-local pool for each size and dump to a
shared pool?
No. We should be, but we've not moved to a single page-size pool yet. I
hope to move to this design as
On 13-07-04 09:02 AM, Huon Wilson wrote:
Hi,
Corey Richardson has hooked up a spare computer to be a basic [bench
slave]; and I've played around with an interface showing timing and
memory profiles, [IRSY]. (It's very much in progress; e.g. I'm going to
add the information from -Z time-passes
On 13-07-03 11:32 PM, Lilly Matsson wrote:
Hello!
I recently made a post on Reddit
(http://www.reddit.com/r/rust/comments/1hk25r/rust_on_64bit_windows_7/)
asking about 64-bit Windows support, and kibwen urged me to post here to
start some kind of discussion about the current state of 64-bit
On 13-07-04 12:12 PM, Matthieu Monrocq wrote:
I thought that .po files were mostly used to translate bits and pieces,
such as strings used in GUIs, and not full-blown text files such as
tutorials ?
This is what it was designed for. But it appears to have been extended
to use in documentation
Win7 pro SP1 x64, smoketest of download, install, compile and run test
program (using std and extra::base64), opt and non-opt, works ok.
(Assuming the laborious and sadly not-made-any-better-in-this-release
dependency-meeting procedure on windows)
-Graydon
On 13-07-03 05:06 PM, Tim Chevalier wrote:
I don't know of any such proposal already, so I encourage you to take
the lead. Of course, even with the translations in the tree, there's
the risk that they could become out of sync with the English version,
but that's preferable to not having
On 13-07-02 02:25 PM, Corey Richardson wrote:
On Tue, Jul 2, 2013 at 5:07 PM, Graydon Hoare gray...@mozilla.com wrote:
(and absent people saying they need it, it isn't like it would be the
sort of thing that would be hard to add to a later version of the
language)
No, it's conceivable, just
All test pass on ubuntu 12.04 LTS.
I've disabled the util-doc builder for the night so we have a doc tree
we can snapshot along with the RC, if it turns out to be the one we
want. Bors I've left running, as there's a long queue to drain.
-Graydon
___
On 13-06-28 11:23 AM, Niko Matsakis wrote:
Specificity is the cost of non-virtual dispatch. However, if it is
truly undesirable in some cases, we can eventually permit you to
return `~Iteratorint`, once ~-objects work properly.
This is interesting. I assume we'd want these to be Iterator cast
On 13-06-24 09:10 AM, Michael Woerister wrote:
This still leaves open the question of internal runtime structures, such
as heap boxes, vecs, and possibly pointers.
Unsafe and region pointers seem to be regular machine-word sized values,
but I think I read somewhere that some pointers (to
On 13-06-17 05:57 PM, Graydon Hoare wrote:
Hi,
As part of preparation for 0.7 (due around the end of june / early july)
we're going to be closing the tree for a while, fixing the lingering
breakage that's snuck through 'auto' and accumulated on 'master', and
greatly widening the 'auto' coverage
Hi,
Some clever folks on #rust have pointed out that there is a (somewhat)
exploitable security flaw in the way bors consumes r+ comments.
Specifically, github permits a repository owner, in some circumstances
(which we can't quite figure out) to _edit comments of other people_ on
commits in
On 13-06-24 07:05 PM, Daniel Micay wrote:
Also, not just the head commit because someone could reset and force push. :P
Bors only pays attention to comments on the head commit, and comments on
commits adhere to that specific sha1 only. This is intentional.
The part where users can edit
On 13-06-18 12:07 PM, Bill Myers wrote:
For Rc, it should be enough to have the GC traverse raw pointers that
have/don't have a special attribute (probably traversing by default is
the best choice), as long as the raw pointers have the correct type.
Obviously it only makes sense to traverse
Hi,
As part of preparation for 0.7 (due around the end of june / early july)
we're going to be closing the tree for a while, fixing the lingering
breakage that's snuck through 'auto' and accumulated on 'master', and
greatly widening the 'auto' coverage such that this stuff doesn't build
up
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much more
readily solvable problems. A 80kloc library does not need to be
generating 16mb of
On 15/06/2013 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
contains one more call to drop, so the code grows quadratically with the
number of allocations.
Yes. Last time I was in the landing pad code (on the return-unwind
branch) I
On 15/06/2013 9:49 AM, Patrick Walton wrote:
On 6/15/13 1:26 AM, Graydon Hoare wrote:
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much
On 15/06/2013 12:25 PM, Patrick Walton wrote:
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help my particular use case. (It would also
help us land
On 15/06/2013 12:44 PM, Björn Steinbrink wrote:
On 2013.06.15 12:25:49 -0700, Patrick Walton wrote:
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help
On 13/06/2013 2:27 PM, Graydon Hoare wrote:
We've deleted the `incoming` branch on github. It was a temporary
measure until we had sufficiently solid auto-integration, which we now
have in the form of bors and the `auto` branch.
The tree will be closed for part of today in order to mop up
On 12/06/2013 1:33 PM, Ziad Hatahet wrote:
On Wed, Jun 12, 2013 at 1:08 PM, Gareth Smith
garethdanielsm...@gmail.com mailto:garethdanielsm...@gmail.com wrote:
My rust code breaks every time I get the latest incoming anyway -
and it is a pretty mechanical change.
I agree. There are no
On 10/06/2013 1:30 PM, Patrick Walton wrote:
I vote for removing all freestanding functions and turning everything
possible into a method. I've been meaning to do this and haven't gotten
around to it yet; any help would be much appreciated!
While I agree in principle, I feel this move
On 08/06/2013 3:06 PM, Brian Anderson wrote:
I've been tracking the numbers of [open] and [closed] issues on the Rust
maturity [milestones] for four weeks. These milestones are currently our
best gauge of progress toward language stability. I'm not sure if it
will lead to anything useful, but
On 13-06-06 09:03 PM, Bill Myers wrote:
Reference counting is generally more desirable than garbage collection,
since it is simple and deterministic, and avoids scanning the whole heap
of the program, which causes pauses, destroys caches, prevents effective
swapping and requires to tolerate
On 06/06/2013 8:59 AM, Gábor Lehel wrote:
Am I way off base with this? An embarrassing misconception? To summarize
my train of thought
* Catchable exceptions can be implemented
* But we don't want to, because it would force everyone to think about
exception safety
* That could however be
On 05/06/2013 9:15 PM, Patrick Walton wrote:
On 6/5/13 9:09 PM, Daniel Micay wrote:
I think extending the built-in `for` loop to work with external iterators
should be considered, because right now the verbosity discourages
using them
and makes borrow checking more painful than it has to be.
On 30/05/2013 9:09 PM, Robert O'Callahan wrote:
FWIW shadowed local variable declarations have been a source of some
frustrating bugs in Gecko. In a big function you see a use of 'x', and a
declaration of 'x', and assume they're related, but they're not.
I'll take that as a vote for a lint
On 13-05-31 08:57 AM, Niko Matsakis wrote:
I was reading Armstrong's [review of Elixir][1] and I thought this
paragraph was interesting, given our recent discussions about
backwards compatibility in Rust. Basically he argues for tagging code
with the version of the language it is targeting. I
On 13-05-31 11:55 AM, Daniel Farina wrote:
I've been poking around in rustc, after noting that compile times are
much longer than I'd expect.
So while some micro optimizations may help, I'm wondering if anyone
has given a lot of thought as to how to make the llvm passes faster or
parallel,
On 29/05/2013 6:48 AM, Gábor Horváth wrote:
Hi!
The following code snippet is well formed and prints 6:
fn main() {
let x = 5;
let x = 6;
println(fmt!(%?,x));
}
I was told this behavior is intentional. However I consider this pattern
as a potential source of errors.
It is intentional. It
On 13-05-28 09:03 PM, Alex Crichton wrote:
Now this doesn't sound that bad in theory. Normally rusti is for quick
computations. There's not much of a history and nothing really takes a
long time. This quickly becomes a problem though for anything which
uses resources. Let's say that you call
On 13-05-29 12:51 PM, John Mija wrote:
How could be integrated the Go language in Rust?
To embed a language, it generally needs to present a cdecl callable
interface (= accept C callbacks), and be willing to schedule its
coroutines and IO operations as steps within someone else's event loop.
It
On 13-05-29 02:40 PM, Gábor Lehel wrote:
Maybe I'm unusual. But in C++ I'm always super-careful (one might say
anal retentive) about keeping my headers as clean of implementation
details as humanly possible. I don't think forgetting a `priv` would
ever be an issue. But I'm not everyone.
On 28/05/2013 1:53 PM, Benjamin Striegel wrote:
A few days ago I submitted a pull request to convert str::as_c_str()
from a function into a method on strings:
https://github.com/mozilla/rust/pull/6729
And today in IRC there was a discussion regarding the fact that Rust's
strings are
On 13-05-25 11:36 AM, Gareth Smith wrote:
On 10/05/13 01:45, Graydon Hoare wrote:
On 13-05-07 08:09 AM, Sanghyeon Seo wrote:
Here are some feature requests to bors queue status page at
http://buildbot.rust-lang.org/bors/bors.html
3. OUTDATED state, for pull requests that need to be rebased
On 23/05/2013 3:33 AM, Tom Lee wrote:
Can anybody out there offer some clarification about the following?
* What are glue_fns and why are they necessary? How/why do they differ
from shim_fns (used to invoke foreign functions)?
Glue functions are invoked by the compiler when types are
On 21/05/2013 4:50 AM, Vincent O. wrote:
The issue is the same with owned boxes. Is it the intended behavior ? in
this case, is there any workaround ?
You're running into one of the motivations for Niko's work on trying to
unify our treatment of unknown-sized types:
On 15/05/2013 8:37 PM, Huon Wilson wrote:
Hi,
I spent a few hours hacking together a performance graph thing[1] that
takes the compile and test times from the auto buildbot and plots it,
ala arewefastyet.com.
*applause* that's excellent, thanks!
I wonder what on earth changed in #6417 that
On 12/05/2013 8:00 PM, Bill Myers wrote:
This is a suggestion for adding an exception system to Rust that
satisfies these requirements:
1. Unwinding does NOT pass through code that is not either in a function
that declares throwing exceptions or in a try block (instead, that
triggers task
On 13-05-09 10:49 PM, Mikhail Zabaluev wrote:
I agree. And if expressions are in Rust, you get the benefit of a Rust
compiler validating them. A lambda must produce _some_ string to be
valid; match clauses will be checked for correct type and coverage.
Dynamically interpreted syntax engines
On 13-05-09 04:26 AM, Matthieu Monrocq wrote:
However, I am not too sure about the idea of string - string mapping.
The example you give here is actually slightly more complicated because
there are several orthogonal axes:
Hm. I think you're missing what I mean. I mean that the interface --
On 13-05-07 08:09 AM, Sanghyeon Seo wrote:
Here are some feature requests to bors queue status page at
http://buildbot.rust-lang.org/bors/bors.html
1. It seems to show no more than 30 pull requests. It used to be enough,
but these days we often have more than 30 pull requests in the queue.
On 13-05-07 09:49 AM, Mikhail Zabaluev wrote:
What do you think of using Rust lambdas for context-sensitive
translations? That could easily accommodate any sort of variance, and
would not complicate the fmt! syntax (though it would require another
fmt-like macro to substitute, as well as
On 13-05-07 09:12 AM, Sanghyeon Seo wrote:
I asked about this in January
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002879.html
and was told 1) request logging was disabled 2) it will probably not be
interesting before the next release.
It has been a month since 0.6 release,
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, OptionT, ...)
This way we have all 3 variants,
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 stable main
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
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-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
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, as
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
On 04/05/2013 12:49 PM, Nathan Myers wrote:
I can explain briefly what worked best in the C++ standardization
process, but will not without invitation from the principals.
I'd be interested in hearing this if it can be made concise, descriptive
and constructive. It'd be remarkable to me if
On 13-05-03 01:12 PM, Brian Anderson wrote:
I agree with reconsidering the inconsistent, underspecified printf
syntax, but don't have any specific thoughts on this at this time.
Note that I made a page collecting links to existing format libraries a
little while back:
On 13-05-03 01:21 PM, Graydon Hoare wrote:
On 13-05-03 01:12 PM, Brian Anderson wrote:
I agree with reconsidering the inconsistent, underspecified printf
syntax, but don't have any specific thoughts on this at this time.
Note that I made a page collecting links to existing format libraries
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
1 - 100 of 466 matches
Mail list logo
