On 12-08-22 12:28 AM, David Rajchenbach-Teller wrote:
On 8/21/12 9:55 PM, Brian Anderson wrote:
Here are some ideas. Servo is probably a fertile area for contributing
to Rust since there are seemingly so many things that will eventually be
needed, but so far we've not been successful at enumerating them.
Core Rust stuff:
* Move bindgen into the rust repo and implement a bindgen pass
(automatically generate C bindings). Involves some unsavory hacking
on the build system.
Do we have documentation on bindgen to which we could link?
As is common in free software, the source repo is the best place to
look: https://github.com/crabtw/rust-bindgen
It's a relatively straightforward tool (though very useful!) It links
against libclang, uses that to read C header files, and emits the
equivalent declarations of external symbols declared in the C header
file as rust. This allows subsequent users of that rust code to link
against the library described by the C header file and call its functions.
The work that needs doing is integration and enhancement. I think,
ideally, we'd like to have a mode wherein it can be used _inline_ in as
a syntax extension, like include_c_decls!("foo.h") or such, as well as
in the "pre-generate the bindings" mode it currently operates in.
* Extract the metadata module from rustc and use it to implement type
safe dynamic library loading.
Same here.
This is quite undocumented, and would require close collaboration with
one of the full timers, likely Brian, Patrick or myself (guessing; chime
in if this is also an area you know!)
* Convert shape code (logging, cycle collection) to visitor code.
Probably not fun.
I am not really sure I understand what this task is all about.
Currently a number of ubiquitous polymorphic actions (copying, freeing,
comparing, garbage-collecting, logging) in rust are implemented through
a system called "shapes". A shape is a .. sort of ad-hoc byte-coded
representation of a type that is emitted in the data section of a rust
binary, used to drive a miniature "interpreter" at runtime (quite fast)
that performs the polymorphic actions on the types in question.
We initially handled such ubiquitous actions by generating per-type
"glue" code -- little helper functions emitted by the compiler
once-per-type -- but found we were generating too much code. Shapes were
our second attempt at solving the problem. They're more compact, but the
supporting code is also comparatively slow, and more seriously, quite
inflexible and hard to maintain and debug.
So we're part way through a _third_ attempt here, hopefully our final
attempt, wherein the compiler emits a single "visitor" function per
type, that drives a callback interface. The ubiquitous polymorphic
actions are then to be implemented in rust code, passing specific
implementations of the callback interface to the visitor functions. We
presently believe this will yield a desirable balance between speed,
simplicity, flexibility and maintainability.
We are only part way complete on this task though. We've built the
interface, tested that it works, and are awaiting "finding sufficient
time" to transition all the shape-using code over to be visitor-using. A
student could possibly do some of this work.
* Get rustc working with the LLVM MC-JIT, with the intent of
implementing a REPL. Several people have poked at this without making
much progress
I like the idea.
We all do! But it will not be a minor task, I suspect. Still, even
standardizing and integrating the front-end-parts of a repl would be a
good step; we have had a few people write them up from time to time and
have so far failed to coordinate centralizing effort on a single one, so
we get some overlapping effort.
Libraries (not all are appropriate for std):
* A general SQL interface with bindings for a few popular DBs.
* An ORM framework - these are popular and useful
* An actor library that encapsulates the actor pattern into something
principles. Take inspiration from Scala actors.
That sounds fun. I suspect that actors (and channel-to-actors, if we end
up doing distributed computations) will end up implementation of traits,
so I guess this will depend on traits.
Traits work today, to a reasonable extent. They lack some features that
are essential for factoring, but I wouldn't consider this entirely
"blocked". We'll be pushing through the remaining significant pieces in
short order; certainly by november.
* XML
I like it. Perhaps with a nice set of macros for pattern-matching?
Yes. I should add to this the integration-into-libstd of a few such things:
- A regexp library. There have been PCRE bindings done before but
I lean a bit towards re2 in recent times. In any case, "a good one",
that we support long-term.
- A library for working with bitstreams, bit patterns, etc. This is
very well supported in erlang and they get a lot of benefit from
taking a pattern-driven approach to packed-binary formats and
protocols. Another place I'd like to follow their lead.
(http://www.erlang.org/doc/programming_examples/bit_syntax.html)
- A classical parser-generator for general CFGs. GLR or Earley or
such. This should, like the previous two, be integrated into syntax
extensions or library code such that grammars can just be written
inline.
(And/or a parser-combinator library with good performance)
- One or more "more robust" serialization libraries. Again, speaking
from current preference, I've noted a couple times my interest in
having a good implementation of avro. Others would like to see a
thrift and/or protobuf implementation.
- More standard data structures. This is some "banging out textbooks"
work, but I would like to see more complete set of containers, at
least alists, functional LLRBs, priority queues, cuckoo hashtables,
digital tries, circular buffers, skip lists, etc.
- Clients for various higher-level internet protocols. The HTTP one
Brian mentioned, of course, as well as things like SMTP, FTP, IMAP,
IRC, NNTP, SSH, DNS, LDAP.
IOW, sure, we always have more work to do than we can possibly do
ourselves. Extra hands very welcome.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
