I'd like to see more foundational libraries along the lines of say. - An Actor/Isolate high level message passing library over Places And Threads. All the necessary low-level primitives appear to be in place to do something interesting and powerful here. - Message passing system should support "remote" Places (i.e. on a different physical node) transparently.
- A dataframe / data panels library along the line of Python's Pandas http://pandas.pydata.org/pandas-docs/stable/index.html - This should leverage existing stat/sci and the new overhauled plot libraries. - A comprehensive implementation of the entire Amazon Cloud API's with an interactive REPL / scriptable DSL for working with same. - A Hadoop integration library Java <-> Racket. (Might be too small for a project.) - Hadoop already supports a StdIn StdOut processing of "scripts". - Implement the necessary custom readers/writers in Java supporting Racket serialized Sexps data files. - Efficient native Racket implementations of newer web protocols such as SPDY and Websockets. Ray On Fri, Mar 2, 2012 at 7:56 AM, Eli Barzilay <e...@barzilay.org> wrote: > A few minutes ago, Robby Findler wrote: > > FWIW, what I had in mind is something lower-tech where we rely on > > the users doing the shared editing to help us out when conflicts > > happen (perhaps coordinating via chat, perhaps using a token they > > explicitly pass around or something). > > The problem with that is that it requires some UI for conflict > resolution, and this UI is bound to be disruptive for the actual > work. The nice thing about editing with etherpad is that you can just > forget about the whole thing, and even if you don't (eg, some laggy > network), then it's nice that it's Not Your Problem... > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > ____________________ > Racket Users list: > http://lists.racket-lang.org/users >
____________________ Racket Users list: http://lists.racket-lang.org/users
