> Sometimes a common header defines the same-named structure, type or macro
> differently depending on your platform.
>
> For example, here’s a definition from termios.h on OSX:
>
> #define CSIZE 0x0300 /* character size mask */
>
> And here’s the same one on some old Linux:
>
> #defi
A suffix ! means that you are using a macro. In this case there is no
difference, but macros are needed for most uses of print functions
since you generally want variable number of arguments, which can only
be done with macros in rust.
jack.
On Fri, Mar 14, 2014 at 3:52 PM, Renato Lenzi wrote:
>
>> We should also use tags: `Rejected` / `Approved`
>
> I'm specifically trying to avoid those words :) 'approved' is stronger than
> I want, because an approved RFC still may not get merged into the language,
> and being 'rejected' is unfun.
XMPP uses the XEP process, which has decent names for t
> I'am learning the functional programming paradigm with rust and to help me I
> decide to translate the pattern of the book "Functional Programming Patterns
> in Scala and Clojure" in Rust. In this work I have a problem to return a
> closure (or a function) as a return value and I didn't find any
> Can anyone elaborate on what this will entail? By "commit message" do you
> mean the honest-to-god git commit message, or the Github PR message, or
> both? What form will the warning take, and how easy will it be to ignore it
> in order to accomodate one-off contributors submitting typo fixes?
S
This sounds pretty interesting. Will it be recorded at all?
jack.
On Fri, Feb 14, 2014 at 9:29 AM, Ian Daniher wrote:
> Hello fellow Rustafarians!
>
> Monday the 17th, at 6pm, at 1000 Olin Way, Needham, MA, there will be free
> pizza for anyone who shows up.
>
> I'll be giving a ~30m talk on my
This might be a recent regression of rustpkg, but rustpkg should pass
through compiler options you give it.
`rustpkg install foo -L some/path` I think is supposed to work.
If nothing else, rustc will definitely take -L arguments. Also, in
your crate source you want to annotate you extern block wi
> What is this algorithm, and what is a concrete example of a set of
> dependencies that your hypothetical algorithm can solve which toposort
> can't?
Doesn't topsort require that you find a single version that satisfies
all dependencies? It's easy to construct things that will work for the
way ru
> I am still confused about:
>
> 1) In what situations are you saying there would actually be a workable
> multi-version solution that wouldn't exist in a system like Maven
> 2) How these solutions are calculated
Every symbol in a crate is hashed with its version. You can load two
extern mod's of
> Rust's safety model is not intended to prevent untrusted code from
> doing evil things.
We'd like something like this for Servo, but I think the idea was to
see if we couldn't use NaCl to do this kind of sandboxing. The NaCl
devs seemed to think this might be interesting as well.
jack.
> used. The makefile macro may be rewritten in CMakeList.txt stuff, but this
> will still generate makefiles and thus don't solve the compilation time.
Our Makefiles are quite inferior to the ones that CMake generates. For
example, if you run `make` on an up to date servo tree, it takes
several se
return the concrete type UniqueChan/SharedChan.
> Functions acting on channels can just use generics, which will allow
> returning.
>
>
> On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed wrote:
>>
>> fn foo() -> T
>>
>>
>> On Tue, Jan 14, 2014 at 9:20 PM, J
d that make us lose stack allocated return values?
>
>
> On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt wrote:
>>
>> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
>> > `SharedChan`?
>>
>> I suppose the main downside of that
> Good point. Make `Chan` a trait with implementers `UniqueChan` and
> `SharedChan`?
I suppose the main downside of that solution is that you lose stack
allocated return values.
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.o
> I'm skeptical about combining Chan and SharedChan. Maintaining that
> distinction is useful for expressing the programmer's intent and would
> certainly make any analysis that cared to distinguish between single and
> multiple producers easier to implement (off the top of my head, knowing
> you'r
The explanation was already given by Corey. It was a normal comment
but mistakenly got promoted by someone to a doc comment. Perhaps it
was a search and replace gone wrong. At least it was amusing :)
jack.
On Mon, Jan 13, 2014 at 7:17 PM, Andrew Pennebaker
wrote:
> I won't bother using git blame
> We've got a little 0.9 release candidate here. I've given it the most
> cursory test, but if you have the inclination go ahead and install these on
> your system of choice and see how it fares. These days we generally claim to
> support Mac OS X 10.6+, Windows 7 and 2008 RC2, a variety of Linuxes
> I may have missed it, but is there a reason not to have just that? Make
> let similar to Erlang’s `=` and fail on refutation?
Erlang is designed around handling failure. It has links, monitors,
supervisors, and so forth. Rust has only some very basic tools for
catching the failure of a task.
I'
>> This is unsuitable as a general purpose mechanism. Whether this is
>> appropriate is highly application specific.
>
>
> I think it's mostly a question of defaults.
I chose my words poorly. I meant that I don't think it's a good
default. Obviously it's a useful tool in many situations.
jack.
__
> Processes overloaded with too many
> messages will slow down and grow in memory until they eventually exhaust
> system resources and crash.
In Erlang this is true, but Rust semantics are different. Memory is
certainly consumed but there is no mailbox scanning like Erlang nor is
there anything li
`extern use foo` has the some of the same drawbacks as `use crate
foo`. The `use` might lead people to think you can do `use crate
foo::bar`. The fact that there wasn't a whole lot of love for any
particular options suggests maybe we should wait for more ideas.
It occurs to me now that `extern foo
Some botnet is picking on #rust. Until the situation is resolved[1] or
the botnet gives up, we've been turning on moderation in the #rust IRC
room.
This means that you won't be able to join #rust or talk in the channel
unless you have registered with NickServ[2].
Right now the attack seems focuse
extern mod msgpack = "msgpack-rust";
jack.
On Fri, Dec 13, 2013 at 7:13 PM, Masanori Ogino
wrote:
>
> Hello. I'm the author of msgpack-rust [1]_, a (incomplete yet) Rust
> implementation of MessagePack [2]_.
>
> I've working on rustpkg-ize the library and now rustpkg-rust can be built
> with lat
Szia!
There is a list of collected presentations related to Servo here:
https://github.com/mozilla/servo/wiki/Videos-and-presentations
and one for Rust: https://github.com/mozilla/rust/wiki/Docs#presentations
The best way to demo servo are the following files which you can find
in `src/test/html
> I just wanted to thank you for the "This Week in Rust" notes. I love
> reading them and I am sure that I am not the only one who appreciates the
> effort that you put into each one.
+1!
These are great. They are the easiest way for us on the Servo team to
estimate how much work we'll need to d
In the latest Rust upgrade for Servo, I noticed that the path API is
now mutate-in-place instead of return a new path. It used to be that
path.push("foo") gave you a new path with an extra component, but now
path.push("foo") returns () and mutates the path in place.
I liked the old API better. I r
I'm at the Toronto summit as well, and I highly recommend any Rust
community members visit our Servo supporting session, especially if
you've ever had thoughts about helping out :)
The Mozilla employee members are bringing Rust stickers to give out as
well, so if you haven't got one, come find us!
>>> Miss it? Did it ever work? This seems like a bug though. Mutability is
>>> inherited, so without this there's no way to do mutable destructuring
>>> bind right?
>> Apparently it went away in commit f9b54541 and the workaround used there
>> is `let (foo, bar) = ...; let mut foo = foo;` etc.
>>
>
> (I miss `let mut (a, b) = ...`!)
Miss it? Did it ever work? This seems like a bug though. Mutability is
inherited, so without this there's no way to do mutable destructuring
bind right?
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail
> .Net style, but using ALL CAPS when the whole name is the acronym.
>
> Examples:
These examples are more germane to Rust, and seem a little
inconsistent under your rules:
GC
GcMut
RC
RcMut
ARC
RwArc
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.
>> Thoughts/straw poll?
>
> I prefer .NET style and have thus far been on a crusade to convert the
> standard libraries to this convention.
+1 for .NET style. There are often multiple acronyms in a row, and
then it's really hard to parse. Also with .NET style, you get working
M-f and M-b in emacs,
> - No-pattern form now requires a dummy pattern. That is, we can't do:
>
> for 10.times { ... }
>
> anymore, rather we have to write:
>
> for _ in 10.times() { ... }
I will not cry much if this happens; it is a bit clever, but maybe we
could save it by using loop:
loop 10.times
> I'm hitting this in workcache and json now. Stuff that the author didn't
> think to make cloneable or comparable impls for. Since I'm in the same
> source tree now I can fix it, but if it was in a different crate I didn't
> control, I'd be out of luck.
After converting Servo to Rust 0.6, I had t
> "change code like this: println!("The result is %f", foo);
>to this: println!("The result is", foo)"
>
> These sound like they're ... in the wrong spirit, to me. Obviously some
> output should be un- or lightly-formatted (logging, diagnostic, raw-data
> output, json, tabular stuff, etc.) bu
>> 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 motivation is to make the tool
you reach for fi
I saw https://github.com/mozilla/rust/pull/7779 come up today and
commented on it. I got to thinking about it some, and since the bug
doesn't seem the right place for such discussion, I wanted to bring it
up here.
The PR proposes to rename print!() and println!() to printf!() and
printfln!(). The
> Thanks for the pointer! It's definitely useful to have examples of
> existing things that work really well and that people like.
erldocs (http://erldocs.com) is one of my personal favorites. For a
demo, hit tab then start typing "lists:a" and hit enter on anything
you like. It uses the same data
> I've been working on a proposal to unify Rust's closure type with
> traits. The idea is based on C++ function objects, which allow any
> object which implements the function call operator to be callable.
This kind of stuff is one of my favorite things from Clojure. Having
maps, sets, vectors, ke
>> I use 1 as well. If there's no other opposition, can we add this to the
>> style guide?
>>
>
> I'm in favor, maybe emphasizing to only do this for small structs.
+1
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinf
> AFAIK that's not supposed to happen if task A checks errno (or other
> thread-local value) immediately after returning from the failed call. Tasks
> are switched cooperatively within the scheduler thread.
Those semantics are true I think, and I believe will remain true, but
they are not obvious.
astebin.com/YYPM4uQK
>
>
> On 4/29/2013 10:43 PM, Jack Moffitt wrote:
>>>>
>>>> For the most part, nobody checks. They weighed the cost of those errors
>>>> against the potential performance loss and decided they would prefer to
>>>>
> Maybe we can find a way to incorporate some sort of "section"
> to use when grouping items, methods, fields, etc. I imagine
> we could draw on Markdown's `#`, `##`, `###` notation to
> define sections, subsections, and so forth, but I'm just
> not sure how we would let rustdoc know about it, sinc
>> For the most part, nobody checks. They weighed the cost of those errors
>> against the potential performance loss and decided they would prefer to
>> go fast.
>
> In C the checking is just too ugly without operator overloading. In C++ you
> can make it look nice, but it's a lot more expensive th
> As was pointed out earlier with Mozilla source code, integer overflows
> "do not happen". Probably because, in security-conscious code, you are
> supposed to validate your inputs for your actual expected range, and
> when you do, built-in overflow checks are just unnecessary overhead.
If you're
> Was this some unsafe-language benchmark shootout? Even if those are
> important due to some "Rust is slow, clinical tests prove it" bogo-PR
> effect, I assume you would disable overflow checking along with array-bounds
> checks in unsafe Rust code.
Clojure basically does this. By default, math o
Kenji Rikitake did similar work in Erlang a few years ago, suggesting
SIMD--oriented Fast Mersenne Twister (SFMT) as a replacement for the
random number generator in Erlang. I believe he also worked on
updating the old Wichmann-Hill generator code from a 1982 version of
the algorithm to a newer 200
> But you can't. In fact, you can't call static methods *at all* through
> typedefs, meaning that this doesn't work:
This has bitten me a few times already, so I'm definitely in favor of
making it work if possible. The rest of your proposal sounds good to
me, although I can't speak for how easy it
> Really? Strings can't just be compared with == ? To be honest, that alone
> is almost enough to put me off the language -- not only is it ugly and
> unwieldy, but it suggests a lot of limitations in the language's memory
> model / type system / operator overloading, which would also make my own
> Any of these sound pleasant to the hear?
I'm fond of Prime.
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
> Con: Even harder to implement than 1, quite complex.
Hard to implement hardly seems like much of a con. This macro is going
to be used a lot, and making it nice seems like something that should
be done, even if it's a bit tricky to do.
jack.
___
Rust-
> A name reflecting its true role seems appropriate. Drawing on
> the Linux kernel experience, I propose "staging". Alternatively,
> "trial", "proposed", "experimental", "unstable".
The Clojure community uses "incubator". It typically signifies
experiments that may end up in the core library or
> I guess the comma should be allowed to be consistent with tuples and
> vectors.
+1
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
> I've recently become aware of the existence of a comma-separated
> local-variable declaration in Rust. Would people object strongly to the
> removal of this form?
I wouldn't miss it.
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.
> multiple tasks. Are there any best practices for wrapping such objects? One
> solution I see is to dispatch all GObject calls through a dedicated
> ever-running task initialized on program startup (GObject needs an explicit
> init call anyway, so it's no big deal to add), but this grand central
>
> rustfix is high on everybody's list of things we would like to have. it's a
> sizeable and difficult project though.
Since I don't think something that could have ported servo is likely
to ever exist, perhaps a good first milestone is just something that
can make the easy changes like removing `
> What needs documented the most? Where should I start to be most effective?
More on the ffi docs that specifically shows callback examples would
be useful. I had a lot of questions about this while updating Servo,
which defines callbacks for some HTML parsing stuff. I'm not sure what
the best exa
> In principle the right pattern for this might be two tasks with the same
> socket? I don't know if rust's socket abstraction would like that or not.
I thought some more about this and I think some kind of non-blocking
read will be necessary. The Erlang way I mentioned must do this in the
library
> What I am really shooting for a is method to query a socket to
> see if there is any data available for reading and if not, go do something
> else for awhile.
Rust has tasks so you can just spawn a task to handle the socket reads
and do other stuff while it's blocking in other tasks. The
non-blo
> FWIW Qt uses `count()`. (but also has size() for STL compatibility,
> and length() as well when it makes sense...)
Clojure uses count as well. I'd prefer size or count, but I suppose
another question is whether verbs or adjectives are preferred for this
kind of thing. That should probably be con
> - This build tool needs a programming language.
>
> - This programming language should not be Rust (to avoid the complexity of
> recursive builds) and indeed should be interpreted.
>
> Any similarly convincing arguments against those beliefs?
I haven't used the go tool much, but I have used both
60 matches
Mail list logo
