diff --git a/Meeting-weekly-2014-01-21.md b/Meeting-weekly-2014-01-21.md index 5cbcc58..ce74b6e 100644 --- a/Meeting-weekly-2014-01-21.md +++ b/Meeting-weekly-2014-01-21.md @@ -12,110 +12,110 @@ # Status -acrichto: mutexes, queue backlog, small 1.0 issues, runtime guide -brson: servo work week, android, roadmap, docs -pnkfelix: Boehm GC integration, Finalization API experiments -pcwalton: servo, mutexarc fixes, Scheduler +* acrichto: mutexes, queue backlog, small 1.0 issues, runtime guide +* brson: servo work week, android, roadmap, docs +* pnkfelix: Boehm GC integration, Finalization API experiments +* pcwalton: servo, mutexarc fixes, Scheduler # Friend of the Tree -brson: Just one thing to do. This weeks' FotT: steven fackler (sfackler). Been contributing since last may; yet another CMU grad! Increble amount of library improvements: base64, bitvector, IO modules. RefCell. io::util module, and most recently, external macro (syntax extension) loading. +* brson: Just one thing to do. This weeks' FotT: steven fackler (sfackler). Been contributing since last may; yet another CMU grad! Increble amount of library improvements: base64, bitvector, IO modules. RefCell. io::util module, and most recently, external macro (syntax extension) loading. everyone: *clapping* # POPL update -brson: Niko's tutorial went really well. Some amazing slides. Room basically filled on both days. Someone was video-taping it too; brson asked the video taping person to send him a copy of the tape. +* brson: Niko's tutorial went really well. Some amazing slides. Room basically filled on both days. Someone was video-taping it too; brson asked the video taping person to send him a copy of the tape. # lang items for primitive impls -acrichto: documentation for primitives via a lang item for the primitive. Technique for documenting primitives. May extend to vectors/strings; not sure. (And also not clear with advent of DST whether it needs to.) -brson: why do you need a typedef? -acrichto: gives you a spot to hang the documentation -brson: why are vectors are problem? -acrichto: because vector types have type parameters, and those type parameters can have bounds in different impls, so its not clear how to present that in the organization provided by rustdoc -brson: think I like what you have for the primitives. -pcwalton: I like it -... (further discussion felix missed) -brson: land what you got +* acrichto: documentation for primitives via a lang item for the primitive. Technique for documenting primitives. May extend to vectors/strings; not sure. (And also not clear with advent of DST whether it needs to.) +* brson: why do you need a typedef? +* acrichto: gives you a spot to hang the documentation +* brson: why are vectors are problem? +* acrichto: because vector types have type parameters, and those type parameters can have bounds in different impls, so its not clear how to present that in the organization provided by rustdoc +* brson: think I like what you have for the primitives. +* pcwalton: I like it +* ... (further discussion felix missed) +* brson: land what you got # env ptrs -brson: At last mtg, we agreed we would move env ptrs to end of list -brson: since then, eddyb has made case for removing it entirely -brson: The reason: once closures are just a trait, then the env ptr will *be* the self pointer of that trait -pcwalton: that makes sense to me -acrichto: one shim per crate, or one shim per call-site? -brson: answer is: there's no shim. (or rather, one shim per function, because...:) -brson: oh this patch also makes it so you cannot coerce fcn ptrs to closures; you can coerce named functions to closures, but not fcn ptrs. -pcwalton: we should do that soon, find out what breaks -acrichto: that changes language semantics. worrisome. -pcwalton: yes. we should land it soon because we need to now what breaks -acrichto: what about one shim per crate? -... (some discussion felix missed) ... -acrictho: i will discuss further with eddyb +* brson: At last mtg, we agreed we would move env ptrs to end of list +* brson: since then, eddyb has made case for removing it entirely +* brson: The reason: once closures are just a trait, then the env ptr will *be* the self pointer of that trait +* pcwalton: that makes sense to me +* acrichto: one shim per crate, or one shim per call-site? +* brson: answer is: there's no shim. (or rather, one shim per function, because...:) +* brson: oh this patch also makes it so you cannot coerce fcn ptrs to closures; you can coerce named functions to closures, but not fcn ptrs. +* pcwalton: we should do that soon, find out what breaks +* acrichto: that changes language semantics. worrisome. +* pcwalton: yes. we should land it soon because we need to now what breaks +* acrichto: what about one shim per crate? +* ... (some discussion felix missed) ... +* acrictho: i will discuss further with eddyb # boehm -pnkfelix: built boehm, doesn't pass tests yet. still uses ref counting. may be useful to add this as a mode for compiling the runtime. should i put in the effort? -acrichto: overrides unique allocations as well? -pnkfelix: currently yes. might not need to override all unique allocations. e.g. c strings could keep using malloc free. -acrichto: unfortunate that std requires all allocations to be through boehm -pcwalton: agree -acrichto: expect that if you link to libgc then allocators go through boehm -pcwalton: isn't this what managed-unique is for? -pnkfelix: that may be insufficient, may need to trace through borrowed pointers. don't know yet if it lets us hook boehm into the entire std lib -acrichto: lang items for allocations redirect through boehm? -pnkfelix: yes -pcwalton: should be experimental -brson: boehm may be sufficent for our gc for awhile? -pnkfelix: don't know yet +* pnkfelix: built boehm, doesn't pass tests yet. still uses ref counting. may be useful to add this as a mode for compiling the runtime. should i put in the effort? +* acrichto: overrides unique allocations as well? +* pnkfelix: currently yes. might not need to override all unique allocations. e.g. c strings could keep using malloc free. +* acrichto: unfortunate that std requires all allocations to be through boehm +* pcwalton: agree +* acrichto: expect that if you link to libgc then allocators go through boehm +* pcwalton: isn't this what managed-unique is for? +* pnkfelix: that may be insufficient, may need to trace through borrowed pointers. don't know yet if it lets us hook boehm into the entire std lib +* acrichto: lang items for allocations redirect through boehm? +* pnkfelix: yes +* pcwalton: should be experimental +* brson: boehm may be sufficent for our gc for awhile? +* pnkfelix: don't know yet http://www.hpl.hp.com/personal/Hans_Boehm/gc/license.txt # fmt::Default -> fmt::Format -acrichto: Motivation is need a deriving mode: #[deriving(Format)] -acrichto: Don't really like this change since this adds stuttering, not sure we need deriving -pcwalton: Weird that errors complain about 'Default' instead of 'Format'. -acrichto: Also could use 'Display', 'Show' -brson: not much better than the reflection-based formatting -pnkfelix: recursively calls Default, so its different -brson: I think we should have deriving, what to call it? Show? -pnkfelix: alex? -acrichto: It's ok. +* acrichto: Motivation is need a deriving mode: #[deriving(Format)] +* acrichto: Don't really like this change since this adds stuttering, not sure we need deriving +* pcwalton: Weird that errors complain about 'Default' instead of 'Format'. +* acrichto: Also could use 'Display', 'Show' +* brson: not much better than the reflection-based formatting +* pnkfelix: recursively calls Default, so its different +* brson: I think we should have deriving, what to call it? Show? +* pnkfelix: alex? +* acrichto: It's ok. # foo_opt => foo -acrichto: Didn't get through this discussion. I'm reluctant to take it -pnkfelix: Philosophy is to not bifurcate APIs. With unwrap noise I think the problem is that the failing one is the easiest to type. -brson: If the goal is to make the failing version harder to type then doesn't making you type '.unwrap()' solve that? -pcwalton: would rather have `.get()`. -nrc: could maybe be solved with some syntax sugar. having to match Some/None is painful, unwrap is less painful, introduces failure, so want something even shorter. Root problem is matching is painful, so make that easier. -nrc: any syntax is going to need to be backwards compatible, so not necessary for 1.0 +* acrichto: Didn't get through this discussion. I'm reluctant to take it +* pnkfelix: Philosophy is to not bifurcate APIs. With unwrap noise I think the problem is that the failing one is the easiest to type. +* brson: If the goal is to make the failing version harder to type then doesn't making you type '.unwrap()' solve that? +* pcwalton: would rather have `.get()`. +* nrc: could maybe be solved with some syntax sugar. having to match Some/None is painful, unwrap is less painful, introduces failure, so want something even shorter. Root problem is matching is painful, so make that easier. +* nrc: any syntax is going to need to be backwards compatible, so not necessary for 1.0 # \xNN escapes in strings -brson: in some languages, denotes what we have (a code point). in other languages, it always denotes a byte (i.e. code unit) -brson: some people prefer one semantics or another -brson: proposal: We officially leave things as they are. Its the semantics of Scheme/Python. -brson: Main downside: won't be able to copy/paste C string literals in all cases between C and Rust -brson: any attempt to copy-and-paste a C string literal making use of this will be detected by the lexer (due to the properties of utf-8). So there's very little danger of this biting people. +* brson: in some languages, denotes what we have (a code point). in other languages, it always denotes a byte (i.e. code unit) +* brson: some people prefer one semantics or another +* brson: proposal: We officially leave things as they are. Its the semantics of Scheme/Python. +* brson: Main downside: won't be able to copy/paste C string literals in all cases between C and Rust +* brson: any attempt to copy-and-paste a C string literal making use of this will be detected by the lexer (due to the properties of utf-8). So there's very little danger of this biting people. # no_mangle for extern fns -acrichto: why isn't no_mangle the default for public extern functions? -pcwalton: because it breaks the module system -pcwalton: if libraries A and B both define extern functions `foo`, if you make no_mangle automatic/implcit, then library C cannot link againt A and B simultaneously -brson: keep it explicit -acrichto: okay. +* acrichto: why isn't no_mangle the default for public extern functions? +* pcwalton: because it breaks the module system +* pcwalton: if libraries A and B both define extern functions `foo`, if you make no_mangle automatic/implcit, then library C cannot link againt A and B simultaneously +* brson: keep it explicit +* acrichto: okay. # crate_type="lib" -acrichto: crate_type="lib". There are a number of different crate types one might select. rlibs and dylibs. But people will want to just write 'type="lib"' and get a reasonable default. But what should that default be? Or should it emit both types of libraries? -brson: What is your opinion of what we should do? -acrichto: I like one default: A compiler-recommend default. -brson: I like having a platform-specific default. (E.g. use-case of emcripten.) Agree default should be static. -brson: And what about a command-line override? -acrichto: Separate issue. If crate says it wants dylib and rlib, but command line says "i just want rlib", that's not going to work. -brson: becaue our command line is additive? -acrichto: because it stacks -acrichto: we could have the command line specify the output format, while the crate specifies the *flavor* of that output format. But I like having the crate specify its output format. +* acrichto: crate_type="lib". There are a number of different crate types one might select. rlibs and dylibs. But people will want to just write 'type="lib"' and get a reasonable default. But what should that default be? Or should it emit both types of libraries? +* brson: What is your opinion of what we should do? +* acrichto: I like one default: A compiler-recommend default. +* brson: I like having a platform-specific default. (E.g. use-case of emcripten.) Agree default should be static. +* brson: And what about a command-line override? +* acrichto: Separate issue. If crate says it wants dylib and rlib, but command line says "i just want rlib", that's not going to work. +* brson: becaue our command line is additive? +* acrichto: because it stacks +* acrichto: we could have the command line specify the output format, while the crate specifies the *flavor* of that output format. But I like having the crate specify its output format.