Meeting weekly 2012 07 03

Attending

Ben, Brian, Eric, Graydon, Lindsey, Patrick, Paul, Sully, Tim

Bug tracking

Graydon: github's issue tracker lacks bug dependency tracking Graydon: don't want to switch to bugzilla yet, but perhaps eventually Eric: github's is more lightweight Graydon: is the bug janitor schedule working? Interns: look at fulltimers Graydon: perhaps the interns should take on bug janitorial work

==== 0.3 status ====

Patrick: I pushed resolve3, not on by default, still in progress, feel free to chip in Patrick: use -Z fast-resolve Patrick: caveat: on very small programs, can be slower 10x; might slow down tests; likely to improve Graydon: I'm comfortable shipping it Patrick: there's a disturbing amount of code that relies on original resolve bugs Patrick: the old one probably will be removed today

==== Macro sigil change ====

Patrick: removing the sigil: no Patrick: Hash is heavyweight, prefix is weird especially if your macro is module-qualified ( io::#println, #io::println Patrick: Postfix-! has problems with assert Patrick: but it looks lightweight; since there's one on the frontpage it should look lightweight Graydon: who likes #? (Ben, Lindsey) Graydon: who likes !? [...] Patrick: I definitely think macros should be the last resort, what you reach for when nothing else works Patrick: I'm mostly concerned with the front page, #fmt looks like a dead spider (https://gist.github.com/3040867) Ben: postfix-$? Graydon: I wanted to hold on to $ for interpolation, and isn't it reserved already? Graydon: lexeme balancing - simple version of macros that gives balanced token trees, that's it Paul: two possibilities - perl style (\ special character, escape delimiter), python style (no special character, no way to escape) Lindsey: I like writing #..[..] for debug messages because it doesn't look like the rest of the code, but for printf it's different Graydon: what about when people want to use macros for new control structures? as compared to the lambda syntax we already have Brian: we do have macros to do control structures, e.g. select (it's basically like an alt) Patrick: "unapply" allows you to overload pattern matching, so you can do regexes, etc. Graydon: "Do they have an operator evaluate that you can overload??" Patrick: I'm happy sticking with # for macro syntax Paul: it's more important for select/alt/etc to look pretty than for less important macros to look ugly Ben: "I DISAGREE!" Eric: having weird macro syntax makes syntax highlighting hard; with macros you can build your own binding forms; in order for an ide to do it right it has to understand the macro language Patrick: the problem with assert is people write assert!(x) and it looks like assert (!(x)), but this is not a problem unless assert becomes a macro Graydon: that will probably happen; fail is probably going to become a library call too Graydon: so how do we decide which sigil to use? Sully: I have dice... general laughter Graydon: so writing balanced tokens between brackets... is "select! {...}" going to be legal? Paul: long-term goal: we'll have a set of expressions surrounded by parens beforehand Graydon: ok, so a macro invocation is a macro name followed by a balanced token tree Graydon: We should stick with # and revisit it if it looks like there are too many dead spiders on the page Eric: is it awful to allow both for a while? Paul: use # for old macros and use ! for new macros, help for migration Ben: if we use ! for macros, will we change bang for negation? Patrick: no, no need (if it's a unary operator); it's unambiguous Graydon: we're killing too much time on this; let's introduce a new one with ! and see how it goes Paul: they will live together in harmony, until we exterminate one of them

==== Buildbot status ====

Graydon: I spent the last few days fighting; convinced that it will work as a replacement Graydon: it has five abstractions that all line up together; you have to figure out .... machines can be thrown into a pool Graydon: we'll do 0.3 and then move to the new one Sully: does this mean that rustbot stuff is all going away? Graydon: yes. rustbot is old & not as good; there will be a new irc bot Sully: do we have something that will make perf graphs? Graydon: not automatically; we'll have to put together a substitute

==== What's up with channel contracts/pipes ====

Eric: pipes are ridiculously fast, 16-17x faster than ports/chans that are in there now Graydon: great news! Eric: graph500 20% speed increase Sully: what makes them faster? Eric: no locks on the fastpath lkuper: and this is possible because the protocol is typechecked? Eric: yeah, also 1-sender 1-receiver Eric: what do people think of me landing & transitioning? Sully: syntax? Eric: currently you write in a language that the protocol compiler compiles to rust code that you then use Graydon: I'd like syntax extensions to be the way we move forward on it; don't want to land something that works one way and have people start using that only to change it later Eric rebases pretty much daily & is a git ninja Eric: running into expressivity issues in the language; usability is painful, hard to get a resource into a closure and be able to move it out Eric: there's some gymnastics each time you spawn a task: ~mut option<...> Eric: copying isn't a big deal because of two endpoints, but if you want to do many-to-one... Eric: we might end up needing copy constructors in the language to do this nicely [Graydon's face looms on the camera...] Graydon: can you get the current awkwardness into syntaxext form and then land it? are expressivity problems preventing it from being usable? Eric: getting a pipe across a task boundary requires 6 loc Eric: going to need some help from the language to make it usable Graydon: we'll do it; this is exciting

libcore/libstd blurring, doubly-linked lists, moving task.rs to libstd

Ben: we want to implement linked failure, other things in libcore Ben: already added doubly-linked list in libcore to make this possible Brian: I would prefer to have it in libstd Ben: actually, I suggest moving task.rs to libstd Everyone: hmm... Graydon: the original justification for the libstd/libcore split was that libstd would be the library that it's ok to have be big, and libcore has to stay small for e.g. embedded systems (and so that you don't have to put use std; at the beginning of a trivial program) Graydon: my feeling is that data structure code isn't huge, so more common data structures should be in libcore, particularly if frequently used Sully: is there an issue wrt snapshotting? Graydon: yes, snapshotting does figure in to this Graydon: original justification for the libstd/libcore split was https://mail.mozilla.org/pipermail/rust-dev/2011-December/001037.html Graydon: it's still early days, could be the case that a fair amount of libstd gets used in every nontrivial program Graydon: all this aside, the runtime library is becoming its own crate and runtime and core are going to wind up being their own library Graydon: Ben, are you ok with just moving more basic data structures into core? Ben: ok, just concerned that it seems arbitrary which data structures get to be in core and which don't Graydon: queues, maps, lists, vectors should be in core Ben: ok Ben: what about @ vs. ~ versions of doubly-linked lists? I need both Graydon: this is a rust-specific concern Brian: how is a unique doubly-linked list even possible? Ben: it's unsafe Brian: we shouldn't expose that Graydon: good point Ben: my hope is that the interface will be safe and it won't hand out unique pointers to its innards Ben: can put data in, get data out Tim: are you basically encapsulating the unsafety? Ben: yes, also the entire list is noncopyable Graydon: why does it need to be a list? Ben: could also use a dvec, could have made operations O(1) with dvecs (as they are with dlists), but it would have been O(n) space in # of tasks Graydon: the O(n) space can be fixed but it's tricky Ben: let's discuss later Graydon: ok Graydon: anyway, it's ok to move more container data structures into core